Bryce, something that might be worth considering as part of this. The first bug report I filed regarding this issue was bug #331918 "Clipped area for multiple X screens with different dimensions" which, because I wasn't sure what the cause was I filed against nvdia-glx-180 and xorg, then later compiz. At the time you told me off for filing against xorg/multiple packages but I've got the feeling that this bug and that are related, on this basis:
There is a common thread that the problem involves the expectation that the system will do something on/related to screen X (where X is greater than 0) but in some way despite specific settings the screen actually used/reported is 0. Since the compiz issue I've been using metacity and it is affected in the same way: screen X commands/actions end up using screen 0. In that other bug Danny Baumann (compiz developer) suggested "It might be worthwhile to write a short test program that just opens an X connection, gets the root window for the respective screen and queries its geometry." I'm not an X programmer and I've no felt like having the additional learning curve to figure that out, although it sounds relatively simple. However, if that is something you could knock together it'd be a quick way for us to test my suspicion that the xserver is returning incorrect information for additional X screens - you'd possibly need to make sure the calls to X are the same ones the compiz code makes to get screen info. -- Multiple X screens launch apps on screen 0 https://bugs.launchpad.net/bugs/336721 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
