Ubuntu

Mouse movement corrupted with Xinerama enabled

Reported by Bob Freemer on 2010-04-14
280
This bug affects 48 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xorg-server (Ubuntu)
Medium
Alberto Milone
Lucid
Medium
Alberto Milone

Bug Description

Impact: mouse movements are incorrect when a display is placed to the left of or above the "primary" display (negative coordinates in use)
How the bug is addressed: revert to having signed ints representing coordinates on screens so that negative coordinates can be properly used
Patch: http://bugs.freedesktop.org/attachment.cgi?id=35383
Testcase: see original report
Regression potential: no obvious regression potential

=== Original report ===

Binary package hint: xorg

The mouse is unusable on a second monitor using the nvidia drivers and Xinerama (Installed: 2:1.1-2). Upon moving to the second screen, the mouse cursor movement is erratic (although it does respond vaguely to physical mouse movement).

The problem was introduced with lucid (and continues in beta 2). The mouse works as expected on the second screen in both intrepid and karmic with exact same xorg.conf and nvidia drivers.

The problem appears even with only the minimal settings in xorg.conf to enable dual monitors. The problem appears whether the second monitor is rotated or not rotated. The problem does not occur with nvidia's TwinView implementation.

The mouse and all other aspects of X work fine in lucid *without* Xinerama enabled. Enabling Xinerama causes no problems except this one. The bug is not present in Debian unstable.

The new bug of course forces one to use separate X servers when wishing to rotate only one monitor in a set -- a limitation that was not present in prior releases of Ubuntu or other distributions.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+5ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-20.30-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Wed Apr 14 09:15:52 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406)
MachineType: Gigabyte Technology Co., Ltd. EP45-UD3P
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-20-generic root=/dev/mapper/vg0-root ro
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
Xrandr:
 Error: command ['xrandr', '--verbose'] failed with exit code 1: Xlib: extension "RANDR" missing on display ":0.1".
 RandR extension missing
dmi.bios.date: 04/16/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F9
dmi.board.name: EP45-UD3P
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF9:bd04/16/2009:svnGigabyteTechnologyCo.,Ltd.:pnEP45-UD3P:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnEP45-UD3P:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: EP45-UD3P
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: x86_64
 kernel: 2.6.32-20-generic

The person that submitted this report seems to have covered everything fine. I am one of the participants in the nvidia forum post he linked to.

I would like to add that I was able to recreate the issue with both the nvidia and Nouveau drivers.

I am currently dealing with this simply by masking package updates to xorg and using xorg 1.6.3.901 on my main tower.

I am also experiencing this problem. I was also able to reproduce this by placing my second monitor above or below the primary.

Did some quick testing. This also exhibits the same behavior on my system:

    Screen 0 "Screen0" 0 0
    Screen 1 "Screen1" Above "Screen0"

or

    Screen 1 "Screen1" 0 0
    Screen 0 "Screen0" Below "Screen1"

Disabling Xinerama removes the symptoms.

Download full text (3.2 KiB)

Created an attachment (id=32354)
Patch for issue

Here's a description of what happens for me along with a patch that seems to fix my problem... My Xinerama setup is as follows:

    Screen 0 "Screen0"
    Screen 1 "Screen0 (2nd)" RightOf "Screen0"
    Screen 2 "Screen1" Below "Screen0"
    Screen 3 "Screen1 (2nd)" RightOf "Screen1"
    Screen 4 "Screen2" Below "Screen1"

Occasionally, X locks up during normal use and you see the mouse cursor "jumping around" the different screens. X is in a tight 100% CPU loop and you can't do anything other than kill it. The easiest way to reproduce the bug in about 30 seconds is to drag a window around between the screens like crazy...

The problem seems to be that there's some sort of nasty feedback loop that causes events to be fed into the event queue while the event queue is being processed:

(gdb) bt
#0 mieqEnqueue (pDev=0x85441c0, e=0x85787a8) at mieq.c:148
#1 0x0809dfc0 in miPointerWarpCursor (pDev=0x85441c0, pScreen=0x82d1a10, x=241, y=7) at mipointer.c:587
#2 0x08154faa in xf86WarpCursor (pDev=0x85441c0, pScreen=0x82d1a10, x=241, y=7) at xf86Cursor.c:473
#3 0x0809dcc3 in miPointerSetCursorPosition (pDev=0x85441c0, pScreen=0x82d1a10, x=241, y=7, generateEvent=1) at mipointer.c:239
#4 0x08109e21 in AnimCurSetCursorPosition (pDev=0x85441c0, pScreen=0x82d1a10, x=241, y=7, generateEvent=1) at animcur.c:266
#5 0x0807a4bc in XineramaSetCursorPosition (pDev=0x85441c0, x=<value optimized out>, y=<value optimized out>, generateEvent=1) at events.c:555
#6 0x0807a72d in CheckPhysLimits (pDev=0x85441c0, cursor=<value optimized out>, generateEvents=1, confineToScreen=0, pScreen=0x0) at events.c:772
#7 0x0807a8e5 in XineramaConfineCursorToWindow (pDev=0x85441c0, pWin=0x83359e8, generateEvents=1) at events.c:650
#8 0x0807ab9e in NewCurrentScreen (pDev=0x85441c0, newScreen=0x82d1a10, x=241, y=7) at events.c:3167
#9 0x080dea32 in mieqProcessDeviceEvent (dev=0x85441c0, event=0x85795b8, screen=0x82d1a10) at mieq.c:388
#10 0x080deb7f in mieqProcessInputEvents () at mieq.c:471
#11 0x080b7cff in ProcessInputEvents () at xf86Events.c:165
#12 0x0809756a in Dispatch () at dispatch.c:407
#13 0x08064d8d in main () at main.c:285

I compared the code in 1.6.5 (which doesn't have this issue) against 1.7.3.902 (which does). It looks like the problem is due to a regression between XineramaCheckPhysLimits and CheckPhysLimits being merged into one single function:

== OLD (dix/events.c; XineramaCheckPhysLimits used for Xinerama)

    if((new.x != pSprite->hotPhys.x) || (new.y != pSprite->hotPhys.y))
    {
    ...
    }

== OLD (dix/events.c; CheckPhysLimits used for non-Xinerama)

    if ((pScreen != pSprite->hotPhys.pScreen) ||
        (new.x != pSprite->hotPhys.x) || (new.y != pSprite->hotPhys.y))
    {
    ...
    }

== NEW (dix/events.c; merged CheckPhysLimits used for Xinerama & non-Xinerama)

    if ((pScreen != pSprite->hotPhys.pScreen) ||
        (new.x != pSprite->hotPhys.x) || (new.y != pSprite->hotPhys.y))
    {
    ...
    }

This patch reverts back to the original behaviour (pScreen check should only do something for the non-Xinerama code path) and this fixes the problem for me.....

Read more...

the de-duplication of CheckPhysLimits was commit 942eae6868b8b0f343b6aa921ddf77e8bb70798a. Assigning to Peter.

Hi,

I built xorg-xserver-1.7.3-902 with the above patch applied.
X doesn't crash anymore but now it stays in "uninterruptible sleep", i.e. it's not usable/killable anymore.
Please tell me if you need additional information on this issue (like gdb or a bisect or so..)

Dec 30 21:41:01 monolith kernel: INFO: task Xorg:4594 blocked for more than 120 seconds.
Dec 30 21:41:01 monolith kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 30 21:41:01 monolith kernel: Xorg D 0000000000000000 0 4594 4574 0x00400004
Dec 30 21:41:01 monolith kernel: ffff88014bf2f860 0000000000000086 0000000000000000 ffff88014e9b143f
Dec 30 21:41:01 monolith kernel: ffffffff814177f9 ffffffff814177f7 ffffffff81494880 ffff88014a990000
Dec 30 21:41:01 monolith kernel: ffff88014bf2fb00 000000000000f888 ffff88014bf2fb00 ffff88014a990000
Dec 30 21:41:01 monolith kernel: Call Trace:
Dec 30 21:41:01 monolith kernel: [<ffffffff8124ebd3>] ? vga_get+0x113/0x170
Dec 30 21:41:01 monolith kernel: [<ffffffff8104c290>] ? default_wake_function+0x0/0x20
Dec 30 21:41:01 monolith kernel: [<ffffffff8124ee60>] ? vga_arb_write+0x230/0x510
Dec 30 21:41:01 monolith kernel: [<ffffffff8110f9d8>] ? vfs_write+0xb8/0x1a0
Dec 30 21:41:01 monolith kernel: [<ffffffff8110fbae>] ? sys_write+0x4e/0x90
Dec 30 21:41:01 monolith kernel: [<ffffffff81012082>] ? system_call_fastpath+0x16/0x1b
Dec 30 21:43:01 monolith kernel: INFO: task Xorg:4594 blocked for more than 120 seconds.

Jochen: hmm, that's a different issue. I'm running 2.6.31 so no VGA arbiter enabled here and I don't see this. See this URL for a patch which should resolve it for you: http://www.nvnews.net/vbulletin/showthread.php?t=142656

Hi, I've applied Tim's patch (on Arch Linux's xorg server 1.7.3.902-1 package, using Xinerama), but with even stranger results. I have two 1680x1050 widescreens.

My setup is:
                 S
                 c
                 r
Screen1 e
                 e
                 n
                 0

Screen0 is rotated to portrait mode. Because Screen0 is on the right (physically), my mouse cursor spawns there on boot. However, when I move my mouse over to Screen1, it wraps back around Screen0's rightmost edge.

So the patch does not work for dual heads with only one monitor rotated.

I disabled the rotation on Screen0, but the same wrapping behavior persists.

(In reply to comment #8)
> Hi, I've applied Tim's patch (on Arch Linux's xorg server 1.7.3.902-1 package,
> using Xinerama), but with even stranger results. I have two 1680x1050
> widescreens.
>
> ...
>
> Screen0 is rotated to portrait mode. Because Screen0 is on the right
> (physically), my mouse cursor spawns there on boot. However, when I move my
> mouse over to Screen1, it wraps back around Screen0's rightmost edge.

I also applied Tim's patch on Arch Linux xorg-server 1.7.4.901 with no success.
I observed the same weird wrapping behavior. The 3 screens configured on my machine are as follow:

    Screen 0 "Screen0" RightOf "Screen1"
    Screen 1 "Screen1" 0 0
    Screen 2 "Screen2" RightOf "Screen0"

So simply moving the mouse on the third monitor make it warp to the first monitor (and not on the third monitor as expected...).

After some thinkering, if I put the screens in ascending order in the xorg configuration, the patch seems to work properly!

I ordered my screens like this:

    Screen 0 "Screen0" 0 0
    Screen 1 "Screen1" RightOf "Screen0"
    Screen 2 "Screen2" RightOf "Screen1"

Applying this patch also worked for me.
As stated by Christian the screens need to be arranged in a specific order otherwise the mouse wraps around instead of moving to the next screen.
In my case I had to also flip the definitions of screen0 and screen1.

Section "ServerLayout"
    Identifier "X.org Configured"
    Screen 0 "Screen0" 0 0
    Screen 1 "Screen1" below "Screen0"
    InputDevice "Mouse0" "CorePointer"
    InputDevice "Keyboard0" "CoreKeyboard"
    Option "Xinerama" "1"
EndSection

This bug is now open for ~3 months, it is a serious regression for many X users and no working bug fix is yet available. Wouldn't it be time to actually bump it up in priority a bit? Like in a lot?

Created an attachment (id=33851)
0001-dix-fix-cursor-screen-check-for-xinerama-setups.patch

Tim, can I please have your signed-off-by for this patch (it's yours with another ifdef and a commit message). I want to get this patch upstream, but I can reproduce the issue even with the patch applied. So I don't think that's it just yet.

hmm. on more testing - looks like this line should just be removed, unconditionally. even if that's not the same code path as we had before. also, I just found out that my test method was broken (wacom was good to reproduce but it'd also screw with the screens).
not sure about this yet, will update when I know more.

Peter,
Should we test 0001-dix-fix-cursor-screen-check-for-xinerama-setups.patch
or do you have nothing else in the works
-james

> Should we test 0001-dix-fix-cursor-screen-check-for-xinerama-setups.patch
> or do you have nothing else in the works

don't worry about testing it for now, I think it's still broken. thanks for
asking though.

Created an attachment (id=33908)
0001-mi-ignore-fromDIX-argument-in-mieqSwitchScreen.patch

Please give this one a test. It seems to fix the problem for me though I'm not sure if there are hidden side-effects.

(In reply to comment #17)
> Created an attachment (id=33908) [details]
> 0001-mi-ignore-fromDIX-argument-in-mieqSwitchScreen.patch
>
> Please give this one a test. It seems to fix the problem for me though I'm not
> sure if there are hidden side-effects.

sigh. no, this one isn't correct either and it looks like there's a race condition in the wacom driver caused by xf86XInputSetScreen that triggers more-or-less the same bug though through a different codepath.

So for now I'd go with Tim's patch (Tim - I still need your signed-off-by for the patch) and my reproducer needs to be fixed elsewhere.

Created an attachment (id=33939)
0001-dix-fix-cursor-screen-check-for-xinerama-setups.patch

Understood -- here's the patch with the Signed-off-by added. I guess something is still not quite perfect as people are reporting that Screens need to be added in a particular order in your xorg.conf but at least this takes it back to the previous state of things.

Cheers,

Tim

Bob Freemer (bob-freemer) wrote :

Binary package hint: xorg

The mouse is unusable on a second monitor using the nvidia drivers and Xinerama (Installed: 2:1.1-2). Upon moving to the second screen, the mouse cursor movement is erratic (although it does respond vaguely to physical mouse movement).

The problem was introduced with lucid (and continues in beta 2). The mouse works as expected on the second screen in both intrepid and karmic with exact same xorg.conf and nvidia drivers.

The problem appears even with only the minimal settings in xorg.conf to enable dual monitors. The problem appears whether the second monitor is rotated or not rotated. The problem does not occur with nvidia's TwinView implementation.

The mouse and all other aspects of X work fine in lucid *without* Xinerama enabled. Enabling Xinerama causes no problems except this one. The bug is not present in Debian unstable.

The new bug of course forces one to use separate X servers when wishing to rotate only one monitor in a set -- a limitation that was not present in prior releases of Ubuntu or other distributions.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+5ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-20.30-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Wed Apr 14 09:15:52 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406)
MachineType: Gigabyte Technology Co., Ltd. EP45-UD3P
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-20-generic root=/dev/mapper/vg0-root ro
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
Xrandr:
 Error: command ['xrandr', '--verbose'] failed with exit code 1: Xlib: extension "RANDR" missing on display ":0.1".
 RandR extension missing
dmi.bios.date: 04/16/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F9
dmi.board.name: EP45-UD3P
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF9:bd04/16/2009:svnGigabyteTechnologyCo.,Ltd.:pnEP45-UD3P:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnEP45-UD3P:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: EP45-UD3P
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: x86_64
 kernel: 2.6.32-20-generic

Bob Freemer (bob-freemer) wrote :

Same problem here. Also if I try to drag a window from the affected screen, xorg crashes and restarts.

Peter,

Any chance of getting the current patch merged so it can at least make it into the next 1.8.x release?

Cheers,

Tim

And the performance seems to be bad in Xinerama.

PS: I run I386, so it also seem to affect that architecture.

Bryce Harrington (bryce) on 2010-04-15
affects: xorg (Ubuntu) → nvidia-graphics-drivers (Ubuntu)

commit 5f31e2196179f8db3170d65a17d8ad40da1acb0d
Author: Tim Yamin <email address hidden>
Date: Mon Mar 8 12:45:15 2010 +1000

    dix: fix cursor screen check for xinerama setups.

Bob Freemer (bob-freemer) wrote :

Rotating as above using xrandr and the nouveau drivers (as in lucid repository) works fine. But of course the nouveau driver doesn't support 3D or even all the 2D features. And the nvidia driver doesn't support xrandr. So no optimal workaround yet that I can find.

I have the same problem when Xinerama is enabled on NVidia drivers using 2 nVidia 9600GT display adapters and 4 displays. Two of the displays are pivot rotated and two are not rotated. I'm using ratpoison as window manager so it's not related to window managers. When I disable Xinerama the mouse works OK but I cannot "throw" applications from display to another.

I love Ubuntu, but display system has always been perhaps the weakest links of it. On Ubuntu 9.04 NVidia display driver (or X or Xinerama or XRandr) crashed the X every few days. On Ubuntu 9.10 there were mouse jumping problems and not always possible to move mouse from screen to screen and in the first releases there was mouse visible on all four screens at the same time and now Ubuntu 10.04 has this new problem where it is impossible to move mouse from screen to screen using Xinerama. I know it's still only Beta 2 but because of history of unsolved problems I'm really really afraid that this will never be fixed.

Bryce Harrington (bryce) on 2010-04-19
tags: added: regression-potential
Bryce Harrington (bryce) wrote :

I'm declining the lucid nomination and setting importance to medium for the following reasons:

  * Given that the bug doesn't occur with -nouveau, this seems likely to be a bug in the -nvidia driver itself, but by SRU policy binary driver updates are not permitted, so this does not qualify for an SRU post-release (and there's no time left to fix it pre-release)
  * There is a functional workaround
  * The issue does not occur for default configurations

Really, I think this bug needs to be communicated upstream to NVIDIA, as it does not seem to be something we can fix in Ubuntu itself. However, just in case I am assigning to tseliot to review it and give additional feedback.

Changed in nvidia-graphics-drivers (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
importance: Undecided → Medium
status: New → Triaged

Bryce, what do you mean by "functional workaround"? I though nouveau driver didnt support multiple cards or am I missing something?

"The issue does not occur for default configurations"... True but with default configuration Gnome uses only one display and with settings (using the gnome tool) I managed it to use only two out of four displays.

For some reason X crashed and failed to restart so I switched to NVidia drivers. Too bad there is issue with the Xinerama.

In case someone finds a way to use four displays (two cards) in Ubuntu 10.04 properly I'd really like to hear about that. I haven't found a solution so far. I even tried to get libxinerama from Debian Testing (v1.1-3) with no luck - mouse keeps jumping. libxrandr2 seems to be in same version so no luck with that neither.

Ubuntu 10.04 Beta 2 release notes says "Because of the new alternatives system used for nvidia driver packages, the nvidia installer from NVIDIA's website currently doesn't work" so I havent tried NVidia drivers from NVidia's website.

Bob Freemer (bob-freemer) wrote :

Dear Bryce,

I understand your reluctance to include in time for lucid. Quite reasonable.

However, perhaps you misunderstood the specifics of the problem? Your second and third bullet points seem inaccuratge.

On the second: A workaround is generally defined to restore full function. The nouveau alternative does not. All 3D capabilities are unsupported by the nouveau driver. This is of course the meat of any GPU.

On the third: Since lucid guides the user to the nvidia binary in it's nicely implemented "Hardware Drivers" dialogue, I believe novice users would expect the resulting upgrade to the nvidia blob to work with distro defaults. As I and others have detailed, it does not.

Unlike some, I agree completely that binary driver bugs have no place in Ubuntu's buglist. But this is an unusual situation; the nv drivers are essentially abandoned. The nouveau drivers aren't quite ready. The nvidia binary works fine in karmic, but doesn't work for the reasons mentioned above in lucid. If it weren't for this last point, I would agree this is a minor bug. But to break new things in the LTS certainly seems visible very suspect for a stable release.

Unless a fix is found soon (I'm still looking), I might suggest regressing the default nvidia blob and xinerama libraries in lucid to solve this bug and let users make the choice to upgrade to the newer (broken) version which is presently lucid's default!

Alberto Milone (albertomilone) wrote :

Subscribing upstream so that they can investigate the issue.

Daniel Dadap (ddadap) wrote :

This is a known bug in Xorg 1.7.

https://bugs.freedesktop.org/show_bug.cgi?id=24986

We did investigate this about a month ago, until we discovered that it was a bug in X. At the time, it did reproduce in Debian unstable, though the bug report here suggests that it currently does not. The freedesktop.org bug report lists an available patch, so it's possible that Debian unstable has applied this patch or their own. It's also possible that the server layout that the original poster tested with in Debian unstable is different: this bug only reproduces when screens with a higher ID are placed to the left of screens with a lower one.

Bob Freemer (bob-freemer) wrote :

Nice find Daniel. My xorg.conf (attached above) which reproduces the bug does not use the old screen ID syntax, but instead uses the new standard "DVI-I-x" where x is the videocard port.

I will fiddle with the screens and ports in xorg.conf and report back with any possible workarounds.

In any case, it's nice to have found the source of the bug. I might suggest a reference be made to the issue in the lucid release notes. Please let me know if I can do anything to provide the release team with any more info or tests that may be helpful.

Bob Freemer (bob-freemer) wrote :

I should have added that the monitor on "DVI-I-2" is to the right of the one on "DVI-I-1." The monitor positions are specified with absolute locations. So my server layout tends to follow the pattern shown in the original bug.

William King (quentusrex) wrote :

I have two Nvidia 9500GT Graphics cards with 4 22" monitors arranged in a 2x2 array. I have the same exact issue as described above.

The nouveau drivers are not an option due to the fact that they will not support more than 1 card. This disables half of my display. Plus this worked just fine in Karmic.

William King (quentusrex) wrote :

This arrangement of monitors works just fine. I can move left and right with no issues at all.

William King (quentusrex) wrote :

The previous working arrangement still uses Xinerama, but on a one row, 4 column arrangement.

The this uploaded version uses a 2x2 version and will reproduce the bug EVERY time. I have rebooted 5+ times for each of the two, changing positions(absolute, and relative) etc but the only thing that seems to cause it is one screen above the other.

William King (quentusrex) wrote :

This particular configuration works just fine. I have two screens, with two monitors each. I change the configuration from screens arranged by row(first and second monitor are on the top screen), and the second screen was the bottom row(see comment #15).

Now with the screens in columns it works fine. I am willing to test code.

William King (quentusrex) wrote :

Forgot to add the conf file.

William King (quentusrex) wrote :

It seems to be(after trying more configurations of monitors inspired by other bug reports), that the mouse bug only happens when the primary screen(screen 0 which is on GPU 0) is located below screen 1. Every single configuration possible from one column, 4 rows, to any combination of 2x2 comes down to the same thing. You can't have GPU0 located below GPU1. If you change the screens physically, or just change the plugs, you can physically put the monitors how you want, just virtually you have to have GPU0 with screen 0 above GPU1.

Changed in nvidia-graphics-drivers (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → In Progress
affects: nvidia-graphics-drivers (Ubuntu) → xorg-server (Ubuntu)
tags: added: patch
36 comments hidden view all 116 comments
Lacey Pevey (lpevey) wrote :

I can confirm that I was hit by this bug, and Mackenzie's patch works perfectly for me. I have a projector screen to the left of my computer. Neither would be easily moved, so pretending my projector screen was to RightOf the main desktop was very annoying. Thank you.

description: updated
damien_d (d-dusha) wrote :

Thank you, the PPA worked for me.

My arrangement, along with xorg.conf files can be found at:
http://ubuntuforums.org/showthread.php?t=1473113

koshcu (kosh-aesaeion) wrote :

With that PPA I am still having the problem with dual 8800GTS cards running 4 monitors.

My original bug report is here and that has all of my setup in it.
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/570151

Koshcu:
Your bug report says RightOf is also broken, not just LeftOf, so I don't think
your bug and this bug are actually the same. For this one, RightOf is a
workaround for broken LeftOf.

koshcu (kosh-aesaeion) wrote :

It has an identical behavior of the mouse getting stuck between screens but I have mine all set as RightOf so no idea what is wrong.

Alberto Milone (albertomilone) wrote :

@koshcu: your bug report is no longer a duplicate.

@Michel: I think that the other issue that you're experiencing is a different bug. Please file a new bug report.

@Pierre Buyle: you're definitely experiencing a different issue. Please file a new bug report.

CpuID (nathan-nightsys) wrote :

Mackenzie's PPA worked fine here, symptoms experienced using standard 10.04 Lucid after dist-upgrade.

Using 3 Samsung 20" screens with 2 NVidia PCIe cards (9600GT with one DVI connection to centre monitor, 9500GT connected to left and right LCDs via DVI). Centre monitor configured as Screen 0.

koshcu (kosh-aesaeion) wrote :

That is not what this bug is about though. I have 4 monitors and from left to right they are 0 1 2 3 so there are no negative numbers to deal with on the x server. There is something else wrong.

Your bug is probably https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/570151 that one.

Mackenzie Morgan (maco.m) wrote :

Koshcu:
This bug *is* about screens with negative numbers. 570151 is *your* bug and
it is NOT a duplicate of this bug. As you said, your bug doesn't involve
negative numbers; thus, you are not experiencing this bug. The debdiff I
attached here and the packages in my PPA fix this bug, not your bug. Your bug
will need a separate patch.

Alberto Milone (albertomilone) wrote :

SRU Request:

TESTCASE: Enable Xinerama and place a screen either to the left of or above the "primary" screen and try to move the mouse cursor to the secondary screen.

The patch is already included in the upstream code and in Maverick (in xserver 1.8). Furthermore the change is safe and unlikely to affect any other component of the xserver as Xinerama is what uses negative coordinates. I believe this fix is a good candidate for inclusion in an LTS release such as Lucid.

Many thanks to Mr. King ! ! !

I Have 2 x 8800GTX's and the Problem is Now Fixed ...
Simply by changing

    Screen 0 "Screen0" 0 1080
    Screen 1 "Screen1" 0 0

         - - TO - -

    Screen 0 "Screen0" 0 0
    Screen 1 "Screen1" 0 1200

-------------------------------------------
now to continue with trying to get 'Compiz' features working.
Never managed Xinarama + Compiz under 8.04 but ho-hum.

William King (quentusrex) wrote :

That is the work around, but the hope is that we have fixed the
underlying bug. I have to admit that I have tried the ppa package, but I
am glad it seems to be working.

It sounds like the LTS package maintainers have two choices. Either add
this patch into the current LTS release version of the package, or
upgrade the package to the fixed upstream version. Can someone find out
which version of the upstream software has the fix included?

On 06/15/2010 09:28 AM, Mr. Francis J. Ball Esq., wrote:
> Many thanks to Mr. King ! ! !
>
> I Have 2 x 8800GTX's and the Problem is Now Fixed ...
> Simply by changing
>
> Screen 0 "Screen0" 0 1080
> Screen 1 "Screen1" 0 0
>
> - - TO - -
>
> Screen 0 "Screen0" 0 0
> Screen 1 "Screen1" 0 1200
>
> -------------------------------------------
> now to continue with trying to get 'Compiz' features working.
> Never managed Xinarama + Compiz under 8.04 but ho-hum.
>
>

Mackenzie Morgan (maco.m) wrote :

Xorg 1.8 has it. Alberto already told me on IRC that he would sponsor the
debdiff I attached, and the reason he and I added explanatory text to the bug
is so that the Stable Release Updates team knows what's going on and will
approve it when he uploads it. Don't worry, the patch'll get in. It's just
going through bureaucracy right now ;-)

William King (quentusrex) wrote :

For those of us who don't know the process(but are interested) what is
the timeline of a bug fix like this one?

It was reported, then confirmed, then diagnosed, then a work around was
found, then a patch was found, a patch was tested and confirmed to work,
then...?

On 06/15/2010 10:21 AM, Mackenzie Morgan wrote:
> Xorg 1.8 has it. Alberto already told me on IRC that he would sponsor the
> debdiff I attached, and the reason he and I added explanatory text to the bug
> is so that the Stable Release Updates team knows what's going on and will
> approve it when he uploads it. Don't worry, the patch'll get in. It's just
> going through bureaucracy right now ;-)
>
>

Mackenzie Morgan (maco.m) wrote :

For bugs in stable releases: https://wiki.ubuntu.com/StableReleaseUpdates

Bugs in general:
For plain old patches that are not upstream yet, subscribe ubuntu-reviewers
and add the patch tag (if the patch had been actually attached to the bug and
marked as a patch rather than just linked, this would have been automatic).
That team will review the patch and send it upstream. If it's urgent (ie,
can't wait for a new upstream release and just go into a future version of
Ubuntu), someone on that team will find someone to make a debdiff (or do it
themself).

For debdiffs or already-upstream patches, subscribe ubuntu-sponsors.

Of course, if the person in the Reviews team who comes across the bug has
upload rights, they can push things through pretty quickly. I don't have
upload rights for main, so while I could do the debdiff and put packages in my
PPA to get the fix confirmed by all you folks, I still needed to point Alberto
over here and ask him to sponsor it.

If you'd like to help move such things through faster in future, learning to
make debdiffs and upload test packages to a PPA would be helpful. Having your
packages tested & confirmed helps make an easier case to the SRU team.

PS: there is an effort to get all patches currently attached to bug reports on
Launchpad reviewed (sent upstream if good, rejected with explanation of what's
wrong if bad, forwarded to sponsors if upstream) by the time 10.10 is
released. That's Operation Cleansweep (
https://wiki.ubuntu.com/OperationCleansweep ) and your help would be greatly
appreciated :)

William King (quentusrex) wrote :

I am interested in becoming more involved in the process. I will read
into what you posted, and will try to find another bug that I can
reproduce.

On 06/15/2010 11:04 AM, Mackenzie Morgan wrote:
> For bugs in stable releases:
> https://wiki.ubuntu.com/StableReleaseUpdates
>
> Bugs in general:
> For plain old patches that are not upstream yet, subscribe ubuntu-reviewers
> and add the patch tag (if the patch had been actually attached to the bug and
> marked as a patch rather than just linked, this would have been automatic).
> That team will review the patch and send it upstream. If it's urgent (ie,
> can't wait for a new upstream release and just go into a future version of
> Ubuntu), someone on that team will find someone to make a debdiff (or do it
> themself).
>
> For debdiffs or already-upstream patches, subscribe ubuntu-sponsors.
>
> Of course, if the person in the Reviews team who comes across the bug has
> upload rights, they can push things through pretty quickly. I don't have
> upload rights for main, so while I could do the debdiff and put packages in my
> PPA to get the fix confirmed by all you folks, I still needed to point Alberto
> over here and ask him to sponsor it.
>
> If you'd like to help move such things through faster in future, learning to
> make debdiffs and upload test packages to a PPA would be helpful. Having your
> packages tested & confirmed helps make an easier case to the SRU team.
>
> PS: there is an effort to get all patches currently attached to bug reports on
> Launchpad reviewed (sent upstream if good, rejected with explanation of what's
> wrong if bad, forwarded to sponsors if upstream) by the time 10.10 is
> released. That's Operation Cleansweep (
> https://wiki.ubuntu.com/OperationCleansweep ) and your help would be greatly
> appreciated :)
>
>

Mackenzie Morgan (maco.m) wrote :

Doesn't have to be one you can reproduce. I don't use Xinerama, but someone
asked me to take a look at the bug.

William King (quentusrex) wrote :

So, if there is a bug out there that has a patch attached. Then the next
step would be that it needs someone to create a test ppa, and build a
debdiff?

On 06/15/2010 12:25 PM, Mackenzie Morgan wrote:
> Doesn't have to be one you can reproduce. I don't use Xinerama, but someone
> asked me to take a look at the bug.
>
>

Mackenzie Morgan (maco.m) wrote :

yep, patches need to be tested, and if you can make a package so its easier
for the affected parties to test, all the better

Alejandro Cuervo (a-cuervo) wrote :

Can someone clarify me if the newly realesed xorg-server at https://launchpad.net/ubuntu/lucid/+source/xorg-server/2:1.7.6-2ubuntu7.1
contains Mackenzie's patch?

If not, can someone tell me how to install Mackenzie's version (2:1.7.6-2ubuntu7.1~maco1) overinding the above metioned release?

Mackenzie Morgan (maco.m) wrote :

It doesn't. You'd have to lock the version as mine is a lower version number.
Alberto should be uploading the fixed one shortly though, so just *don't* use -
proposed until he's done that and you'll be fine.

Alejandro Cuervo (a-cuervo) wrote :

Unfortunately it auto updated to the one on the main repos.

How can I force it to install yours?

Alejandro Cuervo (a-cuervo) wrote :

Got it, I forced it and then locked it.
Thanks Mackenzie

Chris Halse Rogers (raof) wrote :

This has been fixed in Xserver 1.8, which is in Maverick. I'm marking this as fix-released accordingly. I'll get someone to accept the Lucid task for tracking the SRU.

Changed in xorg-server (Ubuntu):
status: In Progress → Fix Released
Changed in xorg-server (Ubuntu Lucid):
status: New → Triaged
importance: Undecided → Medium
Chris Halse Rogers (raof) wrote :

I've added and updated the attached debdiff to the ubuntu-lucid branch of pkg-xorg git. I'll get it sponsored shortly.

I uploaded the package to lucid-proposed shortly after requesting the SRU. Maybe I should have pointed this out.

Accepted into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in xorg-server (Ubuntu Lucid):
status: Triaged → Fix Committed
tags: added: verification-needed
Changed in xorg-server (Ubuntu Lucid):
assignee: nobody → Alberto Milone (albertomilone)
antony73 (toni1800) on 2010-06-21
Changed in xorg-server (Ubuntu Lucid):
status: Fix Committed → Fix Released

@antony73: The fix is still in lucid-proposed, hence it's "Fix Committed".

Please test the package in -proposed and let us know if it solves the problem.

Changed in xorg-server (Ubuntu Lucid):
status: Fix Released → Fix Committed
Jason Stapels (jstapels) wrote :

I installed xserver-common and xserver-xorg-core from lucid proposed and can confirm that they solved my xinerama problem (on nvidia). Thanks!

Martin Pitt (pitti) on 2010-06-22
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.7.6-2ubuntu7.2

---------------
xorg-server (2:1.7.6-2ubuntu7.2) lucid-proposed; urgency=low

  * Add 124_make_xinerama_use_signed_coordinates.patch: Patch from
    upstream to make sure that coordinates are signed in xinerama.
    This is necessary as coordinates can be negative when dealing
    with screens above or to the left of the main screen (LP: #563100).
 -- Alberto Milone <email address hidden> Tue, 15 Jun 2010 15:15:11 +0200

Changed in xorg-server (Ubuntu Lucid):
status: Fix Committed → Fix Released
Alejandro Cuervo (a-cuervo) wrote :

Everything was going well after the xorg-server - 2:1.7.6-2ubuntu7.2 update

Had been crash-less for a while, but then it happened again. once yesterday and again 5 minutes ago :(

Exact same behavior, mouse jumps back and forth between screens, xorg CPU usage skyrockets and the only way is to kill it.

Before the patches it would occur randomly just by moving the mouse between monitors.
Now it still random, but I noticed that in both my crashes it happened while clicking the mouse (without releasing the button) near the boundaries between the screens.

Does the mouse move at all during the clicking? I wonder if it's a
click in negative and release in positive or vice versa...

Alejandro Cuervo (a-cuervo) wrote :

I had a crash again this morning. I can't tell what I did other than simply moving the mouse from one screen to another.
I could not even kill xorg with ctrl-alt-back. I had to login remotely from another computer and kill xorg via the console.

Mackenzie Morgan (maco.m) wrote :

Alex:
You keep talking about it crashing. The original bug report doesn't
mention crashing at all, just that the pointer doesn't move the same
direction as the mouse. I think you may have an additional bug.

Alejandro Cuervo (a-cuervo) wrote :

Mackenzie:
I was having all the symtoms in this bug and they may have been corrected by your patches. Thanks

I should correct my self:
When I said it crashed I really meant it became unresponsive, CPU usage by xorg became extremely high, and eventually had to be killed to regain control of the machine.

What I may be experiencing is: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/570151
which I thought was realted to this one due to the similarities.

Perhaps if this one has been assigned and a fix released, you and/or other experts in xserver could take a look at Bug #570151 that has been confirmed but not assigned.
Thanks for all your work.

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Fix Released
Tyler Gates (tgates81) wrote :

There is an additional patch upstream:
http://bugs.freedesktop.org/attachment.cgi?id=33939
Without it I still get random cursor freezes on ANY video card trying to use Xinerama. I've tested this on 10 or so machines in my company and this weekend I've applied it to all 150 which use a mix of nvidia twinview, matrox xinerama, and various single head displays. I will report back in a few days on stability but I'm pretty sure its good to go.

Tyler Gates (tgates81) wrote :

Reporting Back: Everything has been doing well for 150+ machines.

I've added the xorg-xserver patch http://bugs.freedesktop.org/attachment.cgi?id=33939 as 203_xinerama_stuck_cursor.patch and published an updated package on my ppa, https://launchpad.net/~arnulf-heimsbakk/+archive/work.

I will test it in our work environment and report back if I have the same findings as Tyler Gates.

A late reply, but I'm happy to say that the patch make our work-environment stable. No stuck mouse cursors :)

Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Tyler Gates (tgates81) wrote :

The latest version of xserver-xorg-core (2:1.7.6-2ubuntu7.5) is still giving me the stuck cursor issue.
Can we please get the upstream patch http://bugs.freedesktop.org/attachment.cgi?id=33939 at least into a testing phase for lucid?

Displaying first 40 and last 40 comments. View all 116 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.