Mouse movement corrupted with Xinerama enabled

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

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

And the performance seems to be bad in Xinerama.

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

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.

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.

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.

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!

Subscribing upstream so that they can investigate the issue.

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.

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.

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.

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.

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

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.

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.

Forgot to add the conf file.

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.

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.

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

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.

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.

@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.

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.

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.

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.

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.

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.
>
>

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 ;-)

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 ;-)
>
>

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 :)

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 :)
>
>

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.

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.
>
>

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

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?

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.

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

How can I force it to install yours?

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

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.

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!

@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.

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

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

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...

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.

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.

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.

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.

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 :)

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?