| Summary: | xinerama gives unexpeccted results on unified walls | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Dale Southard <dsouth> | ||||
| Component: | Lib/Xext | Assignee: | Xorg Project Team <xorg-team> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | high | CC: | ajax, alan.coopersmith, dberkholz, kem, roland.mainz | ||||
| Version: | git | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Dale Southard
2004-11-13 21:10:19 UTC
Ideally, the window managers and applications that are Xinerama-aware should be updated to make them to work effectively in both multi-monitor and display wall environments. But, that will take a while to make happen. So, while I don't think changing the X server is the "correct" solution, a workaround is needed while the apps and window managers fix their code. Thankfully, there is a simple workaround to fool Xinerama-aware clients into thinking that the Xinerama extension is disabled, which is simpler than the one above. I'll attach it next. What it does is to exploit the XineramaIsActive library call, which all Xinerama-aware clients use to determine if Xinerama should be used. When this call returns FALSE, the client does not use their special Xinerama-aware code, and falls back to the single screen case. Created attachment 1810 [details] [review] Workaround for display walls Kevin's patch looks good, and is less intrusive than mine. As an additional note, I agree that the correct place to fix this is in the client code. We actually started down that path prior to developing this work-around, and are continuing to push for better xinerama handling in kwin and metacity. Unfortunately, it will take significantly longer than we first hoped for those developers to add that flexibility, so a work-around like this will be necessary for some time to come. applied to HEAD. this patch doesn't document this flag, and i think that's a good thing, it's not something we want people to be relying on, and the toolkits really do need to get fixed to handle this. if you feel strongly otherwise, feel free to reopen with a patch ;) Thanks for commit to head. That's one less local fix we'll be carrying around. RE documentation, I probably would argue that it should be added to the help output in utils.c, but that's largely a matter of opinion. The users I work with know the flag, and the vendors we partner with have the URL for this bug, so they can find it and apply it. Beyond that, it depends on how quickly the desktop people fix their apps. If this patch is still relevant two years from now, I'll probably suggest making it more visible. :-) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.