Bugzilla – Bug 628295
Unsigned cursor coordinates cause crashes and invisible walls
Last modified: 2010-08-16 11:57:33 UTC
Created attachment 380530 [details] xorg-x11-server-7.5_1.8.0-9.4.src.rpm patch User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.2.8) Gecko/20100723 SUSE/3.6.8-1.3 Firefox/3.6.8 Certain multiscreen Xinerama setups like the one described below cause X.org to either segfault or place an invisible wall and rollover when moving cursor around. Example setup: +--------+ |........| |...1....| +------+--------+--------+------+ | | .........|......| | | .........|......| | 4 | 3........|..2...| | | .........|......| +------+-----------------+------+ Cursor movement is possible only in the dotted area. When moving left of the wall in 3, will packman to the right edge of 2. Other layouts like: 3 2 1 4 Produce segfaults when cursor crosses 2-1 and 3-1 boundaries. This is because the relative cursor coordinates are UINT and not INT. This bug will not manifest itself if the first screen is always in the top left of the setup. Xinerama needs to be enabled (separate screens work fine). This is a regression, the problem didn't manifest itself in openSUSE 11.0. Attached patch fixes the problem by making the relative cursor coordinate a signed integer (again ;) This fix has been tested on 11.3 final with nvidia binary driver (cannot test with nuveaueuauau because it doesn't support multiple cards) and xinerama enabled. Reproducible: Always Severity major for breaking Xinerama. Please include in the next maintenance for xorg-x11-server.
Wow!
Coordinates are unsigned throughout X - you shouldn't use signed variables anywhere. The setup you want to achieve shouldn't use 0/0 origin, but rather shift it to the right so that x=0 is on the left hand side of screen 4. Xinerama is unfortunately slowly bit-rotting away, so don't expect too much support by the upstream community...
I'm wondering how you created the xorg.conf for that setup. Has this been done manually or by NVIDIA's setup tool? Which one? I believe there are two of them.
(In reply to comment #2) > Coordinates are unsigned throughout X - you shouldn't use signed variables > anywhere. Those are relative coordinates from the root window. They can be negative. See layout explanation below. > The setup you want to achieve shouldn't use 0/0 origin, but rather shift it to > the right so that x=0 is on the left hand side of screen 4. And then the screen 1 will have negative y coordinate. Can't win. The current setup for me (with patched xorg) is: ^ 3 2 1 4 Identifier "Layout[all]" Screen 0 "Screen0" Absolute 1200 1050 # 2560x1600 (central) Screen 1 "Screen1" Absolute 0 1050 # 1600x1200 @ 90 CCW Screen 2 "Screen2" Absolute 2480 0 # 1680x1050 Screen 3 "Screen3" Absolute 3760 1050 # 1600x1200 @ 90 CW And 0,0 is where the '^" sign is. So I'm not using negative screen coordinates. The negatives are in cursor movements. > Xinerama is unfortunately slowly bit-rotting away, so don't expect too much > support by the upstream community... Yes, I've heard that too. What on earth are we supposed to use instead? Twinview only seems to go as far as single card is concerned and I don't see a way of reproducing Xinerama functionality. RandR support is limited in KDE3 and KDE4 to simple setups and I can't imagine how this is going to get usable any time soon. Any suggestions appreciated.
Created attachment 380570 [details] xorg.conf for this particular setup (In reply to comment #3) > I'm wondering how you created the xorg.conf for that setup. Has this been done > manually or by NVIDIA's setup tool? Which one? I believe there are two of them. You don't seriously think that there is a tool in openSUSE that allows for creation of such setup? :) Even nvidia-settings tool is useless here. xorg.conf attached.
Since you think this is related to the signedness of cursor coordinates you must have looked at the code. Why don;t you debug this some further and try to find out where the cause of the segfault (or the wrong wrap around) is?
Well, I'd love to, but looking at my work schedule for the next couple of months (and I mean the real work, the one that pays the bills) I can see no way I could spend any significant amount of time on investigating this bug further. I hope the attached patch can be included as a workaround and that I won't have to fork xorg-x11-server on my deployments. Best regards, -- grok
Jaroslawy, could you at least bring this up upstream, e.g. on a xorg-devel (http://lists.x.org/mailman/listinfo/xorg-devel) or X.Org's bugzilla (bugs.freedesktop.org)? That would certainly help to get this addressed.
http://web.archiveorange.com/archive/v/ze8GzxyyU5aBTh28mkO5 Seems like it was committed back in May but didn't make it to OS.
Indeed. But that fix was committed after xorg-server 1.8 has been released. Hence it isn't included in openSUSE 11.3.
Right. In which case, since 1) it's an official fix, 2) the bug causes segfault potentially leading to all sorts of nasty stuff and 3) a major X feature is broken, could we please have it included in the next available update for x11?
Fix is now in X11:XOrg/xorg-x11-server and submitrequested for openSUSE:Factory (SR #45632).