X.org will stop responding to mouse clicks on Ibex with Xinerama. Occurs frequently, Fatal Error.

I experienced this same issue also using Xinerama but with only a dual head setup.
I swaped to using a Twinview configuration and have not seen the bug since.
Not sure if Twinview allows greater than 2 monitors, but thought id comment anyway to highlight the Xinerama issue.

I tried switching to a TwinView configuration but unfortunately I can't get it to work correctly in terms of positioning & maximizing windows (which is more painful than it sounds - everything appears, by default between 2 monitors including notifications and popups)

Thinking it might be MetaCity related I tried installing kubuntu to see if that fixes the problem but the same issues happen.

I've found that if I click carefully with my mouse (wait for windows and web pages to load completely before trying to interact with them, try not to use the mouse as much as possible) I can mostly avoid causing the problem for a couple hours of work time, but inevitably eventually something will happen that triggers the bug.

On the upside I'm polishing up on all my keyboard shortcuts...

Hi,

I have the same problem.

Configuration differencies :
Architecture: i686
LANG=fr_FR.UTF-8
VGA compatible controller: nVidia Corporation G86M [GeForce 8400M GT]
2 monitors
And I don't use any 3D effects.

The problem mainly appears when I use ALT+TAB and quickly click on the selected app. But it's not always the case...

I'll try to remove all compiz packages, then try Twinview, then I'll send you a feedback.

Seen this problem all over the ubuntu forums, and all over launchpad..

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/290406
https://bugs.launchpad.net/ubuntu/+bug/296118

I also have the same problem, and as I reported in the forums, I have the same problem no matter what type of mouse I use (all USB)... (one wired, one wireless, and one bluetooth). Happens in Gnome, and also in XFCE if I remember correctly. This is happening on both my work and home computer.

AMD64 + 2GB + nvidia 177 + xinerama (two cards, two monitors).
AMD64 + 2GB + nvidia 177 + xinerama (one card, two monitors).

After a random amount of time (minutes, hours, sometimes a day...) , Mouse only moves, no focus or clicking works. Computer runs find otherwise. Ctrl + Alt + F1 to Ctrl + Alt + F7 does nothing... only Ctrl + Alt + Bksp or Ctrl + Alt + Del gets me back with a working mouse.

Hi Zach,

That sounds like the same problem, I've searched all over the the forums and the Internet in general for anyone with a work around and can't come up with anything.

Seeing as it really seems to be somehow triggered by window focus changes, I switched from focus-follows-mouse to click-to-focus and that seems to have helped some, as the problem didn't trigger for over an hour, but it didn't solve the problem.

Hmm -- I see from the dependencies file that XCB is in use. I wonder if the problem lies in there, somewhere?

-- Thomas Adam

If there is anything I can post from my configuration then let me know... this is my first time using launchpad, and so I am unfamiliar with the process. Also if there is anything I should do if I see the problem again, also please let me know.

I have removed all compiz packages, and the problem is still present.
All my tests have been done with click-to-focus, using a touchpad or cordless mouse.

I am having this issue on a db90000 with xinerama. I haven't been able to get compiz functioning with this setup for whatever reason. Normally it's just go into Appearance -> Effects -> and then check one of those settings, but it is not allowing me to set those complaining the Composite extension is not available I believe. My refresh rate also appears to be a bit slow - when typing text or scrolling in Firefox, the page refreshes really slowly.

I also meant to add in my earlier post, that I have done both an upgrade AND a fresh install and these problems still exist. So it is my belief that it has nothing to do with an upgrade at all.

Exact same issue here. Lose ability to use mouse clicks. Moving mouse still works. Keyboard works.

- Ubuntu 8.10 amd64....
- Linux U810 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
- Xinerama two monitors running on two NVidia's (NV34 [GeForce FX 5500])
- Compiz disabled

Note to self learn more gnome shortcuts.

Ibex + Xinerama seems to be common to everyone affected. I updated the name of the bug to reflect that. Maybe this will trigger someone to take a look..

I am also suffering from the same bug.

thegner@it-thegner:~$ uname -a
Linux it-thegner 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux

Ubuntu 8.10 amd64
3.0 Ghz quad core
8 Gb RAM

I am running three monitors on two nvidia cards (8800 GT / 8600 GT), with xinerama.

I found on a post somewhere to try (sorry no link handy):

Section "ServerFlags"
    Option "AutoAddDevices" "false"
EndSection

This has significantly reduced the number of times that it happens, but it still happens 1-3 times per day.

As with everyone else, the only fix is a full reboot, or an X restart (ctrl-alt-backspace).

Another oddity that I've noticed with this bug, I am still able to alt-tab between apps, and ctrl-alt-arrow, to switch workspaces, but the little notification window that pops up with those actions is seems to be 'stuck' on one monitor, where normally it is on whichever monitor the cursor is on.

As someone else mentioned above with the mouse events on the wrong monitor: I have noticed that the cursor will still change (i.e. to the text beam), but not where it's supposed to, if i have gedit running on my center monitor, the cursor will change on the right monitor in the area that would be the text area if gedit were running on the right monitor. Likewise for a nautilus window on the left monitor, the cursor will change to a text beam on the center monitor in what would be the path space of the nautilus folder. Sorry for the mouth-full on that one, I hope you followed it OK.

I have also disabled my screen saver because others out there have attributed similar problems to gnome-screensaver, but I haven't seen any difference since then.

I'm not sure what else I should provide. If I can be of any help with information of symptoms, let me know.

I just want to confirm that for me going back to Twinview worked. Mouse is fine for more than a day. Working with the bug was not acceptable.

OK, so my computer has just fallen victim to this as we speak... now what should I capture and post here?

Remember that I don't have use of a mouse, so explicit instructions(as I'm new to this) are appreciated...

And oh ya, the sooner the better so I can go ahead and restart ;)

Wish I could edit comments... but I've been noticing that I get this problem a lot whenever I'm using VLC... maybe this has something to do with it? Don't know if this is the reason, but it definitely triggers it some of the time.

Well too late for me, after 30 minutes whole computer locked up. Caps Lock and Scroll Lock blinking.

I have also noticed that using either rdesktop, or vmware workstation seems to trigger it. I also installed the frets on fire game, and simply opening that application and closing it again triggers the bug ever single time. I don't notice the same cursor changing anomaly that described before when triggering the bug that way, but every other symptom is the same.

I also adjusted the screen res for frets on fire to match the screen res of the os, and the bug still triggers. I have not tried windowed mode yet.

As a followup, switching to a TwinView setup only works if Xinerama stays off completely - If I turn on TwinView on each of the two cards and turn in Xinerama the problem will still appear.

If I leave Xinerama off - and so end up with two X screens each of which is spread over two monitors, the mouse will work, it's just not terribly functional the there are two task bars, each of which is spread over two screens and windows can't move between the two screens.

On the upside, it's way faster. And by way faster, I mean I that Firefox in Linux on par with it's Windows version (same machine booted into XP) whereas before something like Google Maps was a exercise in frustration and pain. I'd anticipated that Xinerama was slowing down performance but I had no idea how much...

I've struggled with twinview as well before upgrading to 3 monitors. It will do it's own xinerama type implementation, but I've noticed that the nvidia-settings does not turn off xinerama in the xorg.conf if it has already been set. This is usually only a problem if you merge settings when saving your xorg.conf.

Double check your xorg.conf and make sure you don't still have xinerama enabled, then reboot. That may prevent the task bar from spanning across two monitors.

on a side note, I read that 8.10 was supposed to be implementing some new Xrandr features, that were supposed to allow those of us with multiple displays to can xinerama, but I have yet to figure out how to make that work, or if it's possible with the proprietary nvidia drivers.

I have the same issue as described and I feel that this bug in terms of Importance should move to high Importance.
This renders Ubuntu 8.10 in terms of Productivity to Null.

I have Dual Video Cards; Geforce 8500 - with the Restricted Nvidia Drivers 177 Installed.
I have configured my 3 LG 23" LCD Monitors with Twin View / Xinerama

- Heavy user of Gnome-RDP since Terminal Server Client does not seem to have Clipboard Support
- In essence it seems that this bug will happen when RDP Sessions or VNC Sessions are opened for a long period of time.

I experience this problem approximately 2-3 Times a day, and sometimes more. All keyboard functions still seem to function. Login off my Session with CTR-ALT-DEL and using the keyboard arrow keys to log-off then login back in will allow my mouse to have click functionalities again.

When this bug comes to life, I am able to see my mouse cursor moving, but cannot click on anything. All keyboard keys such as combinations of ALT-Tab and etc... functions.

I have a Logitech Laser Mouse MX Something.

Re-Installed Intrepid as well, fresh Installation with all updates. Ubuntu 8.10 / x_64

Hardware:

- Quad Core Intel Q6600
- 8GB of Memory
- 3x LG Monitors 23"
- 2x Nvidia Geforce 8500 PCI Express Video Cards

MetraDynamix,

Try adding this section to your xorg.conf:

Section "ServerFlags"
    Option "AutoAddDevices" "false"
EndSection

This did not completely eliminate the bug, but it reduced it's frequency by at least half or better. It also fixed some strange keyboard issues I was experiencing with vmware workstation.

I have the same issue. The main difference is that I'm using a Matrox G550 with xinerama instead of nvidia as everyone else here seems to be using. I've been running into the problem on average about once a day. Restarting X fixes the problem. I had been running Hardy for 6 months with no problem on the exact same setup.

After reading this ticket yesterday, I opened an xev on each of my two heads. After loosing the ability to click and change focus I experimented with those two xev windows. It seems that when I move the mouse around the screen0, the xev on screen1 starts showing events. Before the problem, moving the mouse in the xev window produced coordinates around 2080,600. After the mouse problem started, hovering on the xev window didn't produce events, but moving around screen 0 at location 800,600 did produce events and the events had the coordinates 800,600. In other words the events seemed to be coming from a location exactly one screen width ( in my case 1280 ) away from where they were supposed to be.

Also, I noticed that the cursor changed from the usual pointer to the text entry cursor on screen0 corresponding to the placement of windows on screen1, again exactly one screen away.

Just for full disclosure, the xorg mga driver in intrepid is broken and needs a patch to get xinerama working in the first place. See bug 292214 for details. But after finding this ticket, I think my mga issues are independent of this mouse issue.

I have this problem as well using nvidia 177 + xinerama. I'm trying out the twinview fix (kdesudo nvidia-settings => display configuration => configuration => configure => change from xinerama to twinview) with no problems so far. Using twinview, performance is much better and kde4 transparency + desktop effects are now enabled. Thanks for the suggestion!

Throwing another "me too".

x86_64, Ibex, Xinerama (2 screens, 2 Nvidia NVS 290 cards), using the 177.80 nvidia drivers.

This bug has basically chased me off my desktop and back to my laptop. This thing needs attention, and quick.

A quick observation:

After the session has been running for a little while, dragging a window from one screen to the other seems to be a precursor to things failing shortly afterwards.

Another me too. For me, at most it happens once a day. Nvidia and Xinerama. I've switched to twinview as Hops mentioned above (sudo nvidia-settings => display configuration => configuration => configure => change from xinerama to twinview)
It seems to work the same as Xinerama except that compiz now works and it does seem snappier.

Just to make sure everyone is clear. The Twinview option is only viable to those with 2 or less monitors. Twinview does not functionally support 3 or more monitors, so this is still an issue for anyone that is required to use xinerama for this reason.

I have this problem with 2 NVS 285 cards & 4 monitors + xinerama. I have to ctl-alt-backspace to fix it -- about 5-7 times per day. It is REALLY annoying.

Also, to make this ALWAYS happen, start Applications -> Internet -> terminal server client and leave your focus on the "computer" field.

Changing your focus to "password" or "username" field prevents the problem from happening in this instance.

Whoops, to clarify my previous post...to always make this happen,

Go to Applications -> Internet -> terminal server client. Click the right arrow next to "Computer" select the computer and press "ENTER".

You will/should see a ghost menu while your rdp session opens behind it.

After having run into this problem twice within 15 minutes I noticed exactly what I was doing when it happened, and tried repeating it. In both cases, I was moving out of a firefox window on my Screen0 to a window on Screen1.

After a little experimentation, now I can pretty much cause the mouse to quite working withing 30 seconds of trying. Open up two firefox windows and put one each screen, leaving a small gap of background between the firefox window and the edge of the screen. Now flick your mouse between both firefox windows (I have focus following the mouse). For me, within 20 flicks the mouse stops working and starts misbehaving.

I've also gotten it to start misbehaving with two emacs windows, but firefox seems the best choice for reproducing it quickly for me. Someone else should give the above method a try and confirm it reproduces the problem in a short time. Having a quick way of reproducing the problem might help this bug along.

confirmed and killing my productivity...

this may be helpful in tracking it down.

system specs:

Ubuntu 8.10
Intel Q6600 @ 3.2Ghz
Asus P5E WS Pro Mainboard
8GB ram
2 x Nvidia 8600GTS (177.80 drivers)

Screen setup: 3 screens, each a separate x session all merged with xinerama, arranged from left to right as: GPU0(screen0), GPU1(Screen0), GPU1(screen1). All normal orientation and all 1680 x 1050 screens.

Always appears to happen when the mouse is moving across the GPU boundary. And here is the interesting bit that may help solve this. I often run 1 application on each screen but not maximized to the screen, there is a one inch gap or so around the edges of each application window on each screen. The apps that are on GPU1S0 (middle) and GPU1S1(right) have custom cursor icons, when the mouse bugs out, if i move the mouse to GPU0S0 (left) and put it in the area where the windows are on the other screens, the cursor icon changes and moving it around more subtly i can get the various cursor from the apps that are running on the other 2 screens (2 instances of the same app so i can't tell which screen X thinks the mouse is really on). Clicking anywhere has no effect, despite attempts to click on the left screen to create action on one of the others.

Testing: To test this hypothesis i setup 3 instances of xev, one on each screen roughly the same size and in the same place. I trigger the bug (waving mouse back and forth quickly across the gpu boundary seems to be 100% effective at causing this in a short amount of time, thus i recommend everyone avoid doing this when you don't want to reboot X).

results: movement on GPU0S0 (left) in the area of the xev window on GPU1S0 (center) triggers events on the xev on GPU1S0 (center), indicating that X thinks the mouse is one screen to the right of where it is displayed, presses and releases are also recorded although they have no effect on running applications (probably because the coordinates sent to the app are out of bounds). Mouse movement / events anywhere on GPU1S0 or GPU1S1 cause no xev events on any screen indicating its not simply an off by 1 screen issue.

this and everything else we've seen indicates to me this is a problem in handing off cursor control from 1 gpu to the the other gpu.

I'm out of time tonight but i will try disabling hardware acceleration of the cursor to see if it has any effect on this. I could also rearrange my screens to further test the GPU boundary theory.

cheers,

x

I also have this problem.
Ubuntu 8.10 64-bit (updated today)
Nividia 177
Xinerama w/ 4 Screens

Reproduce bug:
1. Open Firefox (with a bunch of Restored tabs including one with flash content)
2. Move Firefox window to different monitor.
3. Right click on the Firefox entry in the "Window List" and select "Move"
4. Left click anywhere. (The mouse clicks stop working)

The keyboard still works fine and the mouse cursor still moves around.
One time I opened a terminal with keyboard shortcuts and ran "sudo /etc/init.d/hal restart" and it fixed the problem. The next time I tried that it didn't work.

Nelson: I tried to reproduce the bug using your steps, but It did not manifest itself for me.

I attached the Xorg.0.log from the buggy session.
I did add Option "AutoAddDevices" "false" to my xorg.conf "ServerFlags" area, but it didn't seem to help.

Same problem here for me

I get the problem mainly following a long period of inactivity.

 Has anyone heard of a fix for this other than going to twinview.

Also I am able to duplicate this bug instantly by using VirtualBox. My mouse is fine until I focus on the VM. the moment i try and change focus back I lose my mouse. Not sure if thats relevant in any way to this bug or if its an issue with VirtualBox, or even just an issue with my setup.

Setup
 Intrepid
 AMD 64 3500+
 Nvidia 6200 (PCIE) & Nvidia 6150 (int) Cards
 177 driver
 Xinerama

How much pressure do we need to exert to get the Importance uprated. its not impossible for me to work with it but its really a pain to resolve when it occurs. I think it definitely deserves to be higher than "Undecided"

Seconded on the importance issue. The only way to resolve the problem that I've found so far is to CTRL-ALT-DEL and kill my entire session. Because not all my apps have decent keyboard shortcuts, they can't all be quit cleanly, resulting in lost work.

Regardless of lost work, it's a major waste of time & effort to restart X just to get back to where you are.

further testing on my setup shows that the bug triggerability is dependent on graphics load, since nvidia xrender performance is....poor....multiple firefox sessions, vmware screens, terminal server screens, all seem to do the trick. Moving the mouse quickly across the gpu boundary with no load will not trigger the bug, but any combination of xrender apps and/or 3d apps running will allow me to trigger the bug very reliably. Interestingly enough, coming back from a long idle can cause it as well, which i could assume, is also a manifestation of the load issue as well as the video cards are "waking up" at this point.

cheers,

x

Me too.

CTRL-ALT-BKSPACE is the only way for me to get my gui back. Multiple driver versions. currently 177.83 from Nvidia, not happening as often, but still happening.

I've been experiencing this bug ever since I upgraded to Ubuntu 8.10 from 8.04.

It seems to mostly be triggered by running 3D games after the game quits, but has randomly happened a couple of times too.

I can get it to trigger in under a minute or so of starting/stopping a game or other 3D app.

This continues under the most recent kernel for Ibex - I'm running 2.6.27-10-generic, fully up to date with all packages in main, universe, restricted and multiverse. And it's absolutely maddening.

Can someone responsible for tracking these issues at least tag this bug with some kind of status/assign it to someone/do something?? It seems like we're shouting into a vacuum here.

marking it specifically as a libxinerama issue.

Looks like this was reported 2 weeks prior (late October) as Bug #290756.

As Peter said, this issue is maddening. Finally fed up with this problem, I downgraded xorg to the version in hardy. Everything is now working well, with no more problems with mouse events.

I wonder if it really is a libxinerama (as in the libxinerama1 package) issue or not because I did not downgrade libxinerama, just xorg stuff and everything now works.

I was having the mouse not responding to mouse event problem reported here until I disabled Xinerama and started using Twinview. Since I've made the changes it has been over a week without a lockup. I followed Randy Wilson instructions from 2008-11-24:

"""Another me too. For me, at most it happens once a day. Nvidia and Xinerama. I've switched to twinview as Hops mentioned above (sudo nvidia-settings => display configuration => configuration => configure => change from xinerama to twinview) It seems to work the same as Xinerama except that compiz now works and it does seem snappier."""

$ sudo nvidia-settings

Select "X Server Display Configuration"
Disable the "Xinerama" checkbox. (This may be on the "Configure..." popup. It's been a week and I don't recall the location.)
On the 'Display' tab select the button "Configure..." and set to "Twinview"

Pascal wrote: "everything appears, by default between 2 monitors including notifications and popups"

This problem goes away if you disable Xinerama.

This fix may only work if you are using two displays.

I'm also having this issue, pretty much as everyone explains it above.

Two NVidia cards, 3 cards.
NVS290 - Center and Right
GeForce 8800 - Left

Twinview won't work with 3 or more screens. nvidia-settings might give you a config that lets you login, but don't count on it being usable. If you hand tune an xorg.conf you can get it looking ok, but the window manager doesn't get any of the monitor boundary info so windows pop between monitors, or sometimes off the screen.

I'll give downgrading the xorg packages a chance tonight, but my next stop will be back to hardy.

I've marked the prior Bug #290756 as a duplicate of this since this bug has more discussion. Please check the other bug for more debug info and output. (Thanks Peter).

Nelson:

Can you post the steps for downgrading the appropriate packages? I've got little faith in this being fixed anytime soon, and it's looking like the only option for the near future.

Thank you.

I'd also be grateful for xorg downgrade instruction :-)

I couldn't find anything about the issue on the 'net and I was feeling kinda lonely. It happens to me also - sometimes after couple of hours, sometimes minutes after X start.

I'm using Dell XPS M1330 w/ GF8400GS; using Xinerama because panel has 1280x800 res and external monitor (attached via HDMI) is 1680x1050, TwinView don't like working on monitors of different res.

In my work, I use both Firefox and VirtualBox and as far my best solution was to use only firefox in VB - no window switching, no bug - but it's not the most comfortable solution.

The problem importance for me - it's critical.

I hadn't expected that others would be so interested in how to downgrade or I wouldn't have taken some notes. Here is what I did as best I can remember:

Logged in to a text console as root and shut down X with '/etc/init.d/gdm stop'.

Add the following lines to my /etc/apt/sources.list :

deb http://us.archive.ubuntu.com/ubuntu hardy main
deb http://us.archive.ubuntu.com/ubuntu hardy-updates main
deb http://us.archive.ubuntu.com/ubuntu hardy-security main

At this point I tried to purge all the xorg packages I could with:
cd /var/lib/dpkg/info/
dpkg --purge `ls *xorg*.list | sed s/.list// `

Obviously it won't remove all the packages because of the dependencies of other packages. I am starting to think that step wasn't necessary as I think the next step would have resulted in those packages being removed anyway. After a little trial and error I found that I needed to downgrade the following packages on my system. ( note I have a matrox card, so please substitute the correct video driver for your hardware in place of the mga driver ):

apt-get --reinstall install x11-common/hardy xorg/hardy xserver-xorg/hardy xserver-xorg-core/hardy xserver-xorg-input-kbd/hardy xserver-xorg-input-mouse/hardy xserver-xorg-video-mga/hardy

After that I restarted the X with "/etc/init.d/gdm start" and logged in and everything worked for me. The final step was to go into synaptic and lock those 7 packages so the upgrade manager would stop bothering me.

This seems to have been misfiled against libxinerama/xorg, when it looks more likely to be an -nvidia problem. Refiling.

[No need to have it open against xorg too]

Bruce,
There is one user experiencing the problem with a Matrox card.

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/296167/comments/25

I'm not sure its an nvidia issue since :
 - Downgrading xorg + friends solves the problem.
 - Switching to twinview works around the issue (i.e. disabling xinerama makes it go away)

Any thoughts ?

I'm not sure whether it's a nvidia issue. I experience the same problems with a ATI Mobility x600 using fglrx drivers with a two monitor setup using xinerama.

My apologies Bryce, Misread your name :)

Just noting that downgrading the xorg package to hardy (1:7.3+10ubuntu10) has resulted in zero occurrences of the bug in the last 24 hours. Previously, I was restarting X at least 3-4 times a day.

In downgrading, I made no changes to the nvidia drivers being used - only the xorg package changed.

Bryce,

This is definitely is not an nvidia specific problem. I have the same issue with my Matrox G550 card. And Schmallon has since reported that he has the same problem with an ATI setup. This issue does not seem related to the video driver being used, but how xinerama and mouse events are interacting.

I just wanted to add that I had the same problem out of a fresh install of Ubuntu 8.10 desktop for x86_64. I experienced the mouse problem several minutes after running vmware. My system has four displays, so disabling xinerama is not an option for me. I downgraded xorg just like "Nelson" had suggested above. The mouse worked for me all day without fail. I am running two nVidia NVS 285 video cards. Thanks, Nelson, for providing instructions to work around this very annoying, time killing and productivity wasting bug. I believe this bug is critical to those of us that rely on xinerama.

This is definitely not an NVidia issue. I fired up my test machine with dual ATI cards, and upgraded to Intrepid, and configured it to use Xinerama. I got bored using it surf (slow) so I just left it for 24 hours. When I came back the mouse would wake up the screen, but no clicks were registering.

I hate to say it, but downgrading to the xorg package that ships with Ubuntu 8.04 isn't a complete solution - I experienced a re-occurrence of the bug today.

That being said, this was after my session had been active for several days, so it's far better than what's going on in 8.10.

I just wanted to chime in and mention that I'm having the same issue as well. Mouse-over events and clicking spontaneously stop working at random. It usually happens when using Firefox, and the only recourse is a ctrl-alt-backspace. I'm going to attempt downgrading my x.org packages as a temporary measure, but I would love to see this resolved.

Confirming that a downgrade to Hardy xorg packages resolves the issue.

Until this is resolved, can someone post a series of steps to downgrade just the xorg drivers under Intrepid?

Dan

(This happens to me too - I'm testing to see if window managers make a difference. Gnome happened after about 90 minutes, KDE took a few hours, I'll try E16 next..)

I am chiming in to confirm that I have the same problem using:
Ubuntu 8.10
NVidia Driver Version 177
Xorg - Xinerama

I can't use twinview as one of my displays is rotated CCW 90 degrees. With Twinview, rotation affects both displays.

But, with one display in portrait and the other in standard configuration landscape, I can consistently recreate the failure by doing the following:
Using Synergy, if I move from the bottom of my client computer screen across to my Linux display, out of the range of my standard screen, the mouse jumps the middle monitor directly to the bottom of the portrait display. Once it skips the main display the mouse clicks are no longer registered. The key to failure on my system is to move the mouse from one display to another where the display area does not reach. When working from the top of all screens there is no problem.

The other way to recreate failure is to allow for a long period of mouse inactivity, and for any of the screens to sleep.

My setup worked perfectly in Hardy. I regret updating my computer as quickly as I did to Ibex, and likely will have to downgrade in order to regain productivity.

Me too. Ubuntu 8.10, Nvidia 177, Xinerama. Like JP, I prefer to have one of my displays rotated CW 90 degrees.

I switched to Twinview yesterday and haven't seen the problem since switching. Before that I was having to restart my X server every 1-2 hours because of this bug.

I can reliably trigger the problem by using x11vnc or vino to share my Xinerama desktop with another computer. After exiting the vnc viewer on the other computer, the mouse would move but no clicks would register. The workaround is to put the mouse cursor at the farthest right edge of the virtual desktop before exiting the vnc client. If you do this, you can usually avoid triggering the bug.

There's a possibly-relevant bug which I thought was due to vnc but is actually probably due to this Xinerama bug: when operating my Xinerama desktop remotely using a vnc client, I could not click anywhere on my first display (the rotated one). Only clicks in the second screen would register. I could move the mouse cursor to the first screen, but I could not interact with anything on that display.

Quick fix for problems arising with Synergy

I am testing my theory that the mouse fails with xorg/xinerama when moving from a virtual screen, e.g. with synergy or vnc viewer, to an area that would be outside of the X screen. Since Xinerama LeftOf or RightOf aligns the top of the screens regardless of the screen size, the bottoms will not be aligned when using two different sized screens or when putting screens in different rotational orientations.

Quick fix for Synergy, set the options to disallow moving between screens in an area that would put the mouse outside of the gui on the x screen.

in /etc/synergy.conf (or wherever you store your synergy conf file) add the following to the remote screen:

section: screens
        clientcomputername:
                switchCorners = bottom-right
                switchCornerSize = 800
        mycomputername:
end

800 is the number of pixels in the specified corner within which the mouse will not move between screens. Mine is 800 because I have a large portrait monitor for viewing scans and documents.

See http://synergy2.sourceforge.net/configuration.html for more info

I don't know if the same can be done for vnc viewer.

I also encounter this problem three or four times per day. I have three monitors on two Nvidia Quadro FX cards, using the nvidia 177 binary driver on 8.10.

I found that when the problem strikes, I can re-enable the mouse with the following steps:
1) Select a window using ALT+TAB.
2) Open the window's menu with ALT+SPACE.
3) Select 'Move' from the menu. The cursor should change to the hand cursor and be positioned in the centre of the window.
4) Move the cursor with the mouse. If this causes the window to move (unlikely), left-clicking should release the window and the mouse should work normally.
5) It's more likely that moving the mouse will just move the cursor and the window will stay put. In this case use the cursor keys to move the window to the primary monitor. If the window is already on the primary monitor, move it to another monitor, then back to the primary.
6) Once the window is on the primary monitor, move the cursor with the mouse. The window should move with the cursor, and mouse events register again.

This works for me every time. It's far from ideal, and I detest this kind of voodoo workaround, but it's better than restarting X. Of course, your mileage may vary.

Haha, I found this workaround independently too. Sometimes random frustrated key-commands actually work.
Thanks for posting it with such good instructions, I was going to do some more testing, but now I don't have to.

I can confirm the above workaround absolutely.

I have the same issue with my HP Pavilion TX1000, with xinerama enabled, and two monitors. My card is:

user@megan:~$ uname -a
Linux megan 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux
user@megan:~$ cat /etc/issue
Ubuntu 8.10 \n \l

VGA compatible controller: nVidia Corporation C51 [Geforce 6150 Go] (rev a2).

Kevin's workaround works, than you.
We well be waiting for the Ubuntu's fix.

Mr. Browne: Thank you!

I walked through these steps when my system was functioning, and succeeded
in re-creating the error (I lost mouse clicks after step 4.).

I was able to 'fix' it by following the steps. Maybe a developer can use
these to re-create the problem with the mouse input?

Dan

My system: Three displays on two NVidia cards (8600 using the 177 driver,
and an older GeForce MX using the "nv" driver), Kubuntu 8.10, 2.6.27-9
kernel.

--
"Quis custodiet ipsos custodes?" (Who can watch the watchmen?) -- from the
Satires of Juvenal
"I do not fear computers, I fear the lack of them." -- Isaac Asimov (Author)
** *** ***** ******* *********** *************

Fix doesn't work for me. My keyboard also stops responding, Originally keyboard worked, but somewhere trying to fix it it stopped responding along with mouse. PC is still processing as I Gkrellm is ticking away, but I have to resort to CTRL - ALT Backspace

I've summarized Nelson's steps for downgrading X.org here:

http://dailyvim.blogspot.com/2008/12/ubuntu-downgrading-xorg.html

Please use those docs for downgrading as the original instructions were missing a step (apt-get update).

Thanks for the detailed information guys!

Upstream bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=18668

Me too.

 I'm running dual monitor with xinerama on my laptop. Except I have an SIS chipset / drivers and not an NVidia. Definitely not only an NVidia problem.

I'm running Xubuntu. The keyboard also stops working as soon as I alt-tab to another program. The workarounds don't work either.

An update on my end:

After a week of running xorg from 8.04 (hardy), I'm still seeing the problem. It's not as frequent as it was, but it's still happening.

With that, I have been able to apply the fix described above (using the keyboard to move a window across the screens & back), which generally seems to work. At some point, however, X seems to really freak out after a few days of use - I've had to restart X twice in the last week on a desktop session that is supposed to remain up.

I can confirm most everyone elses issues with a new install of 8.10 (Intrepid) and the Nvidia Drivers. I have seen the problem in both the Nvidia driver versions 173 & 177.

Currently using an Nvidia GEForce 8800 GTS with (2) monitors setup on Xinerama. I continually have had issue with loss of mouse 'click' function while still maintaining the keyboard control. The problem seems to happen at various points throughout the day, and it is tough to duplicate. I have noticed a pattern where a program will open a second dialogue (especially when it opens on the second screen) and the mouse click functions quit working. It happens often with VLC, Firefox, DeVeDe, and switching back and forth across screens in Nautilus.

Have also tried to get 'out' of the issue without restarting the xserver with Kevin Brown's solution on 12/09, but this solution does not seem to work for me. The only way to get 'out' is to CTRL+ALT+BACKSPACE and login again.

The Nvidia driver version 173 does seem to happen a bit less often. Not too sure I want to mess with downgrading Xorg.

Please let me know if there is anything that can be posted or any way that I can help to resolve this issue.

I can confirm most everyone else's issues with a new install of 8.10 (Intrepid) and the Nvidia Drivers. I have seen the problem in both the Nvidia driver versions 173 & 177.

Currently using an Nvidia GEForce 8800 GTS with (2) monitors setup on Xinerama. I continually have had issue with loss of mouse 'click' function while still maintaining the keyboard control. The problem seems to happen at various points throughout the day, and it is tough to duplicate. I have noticed a pattern where a program will open a second dialogue (especially when it opens on the second screen) and the mouse click functions quit working. It happens often with VLC, Firefox, DeVeDe, and switching back and forth across screens in Nautilus.

Have also tried to get 'out' of the issue without restarting the xserver with Kevin Brown's solution on 12/09, but this solution does not seem to work for me. The only way to get 'out' is to CTRL+ALT+BACKSPACE and login again.

The Nvidia driver version 173 does seem to happen a bit less often. Not too sure I want to mess with downgrading Xorg.

Please let me know if there is anything that can be posted or any way that I can help to resolve this issue.

I'd recommend a downgrade of Xorg. It's taken my problem from once very hour (or more!!!!) to once every few days. I can now use virtualbox, firefox (with flash), and switch windows without holding my breath. I'd prefer a full solution, but if you don't want to downgrade to 8.04 then I reckon it's worth it (and painless).

Quick tip that I wanted to share to get out of the no-click mouse problem. Got this idea from trying variations of Kevin Brown's solution.

Keep holding down Alt+F7 while left clicking and moving the mouse around.. Works for me every time so far. Makes the glitch more livable for now.

Can someone change the package? This is not just with nvidia-graphics-drivers, I have the problem with a SIS chipset.

Matrox G450, Ibex, Xinerama, dual-head, using mga module with same patch as Nelson (#292214)

Exact same problem.. move and click events register one screen to the right of where the pointer appears, but nothing responds to the events except for xev, even if you correct for the shift.

I'm also getting lots of these messages from X on stdout or stderr as I move the mouse around:

Badness: Expose event on a client frame which shouldn't be visible: 0x#######

I'm also using wmii, if that matters

Since the SIS chipset also supports MergedFB I switched to that. Not only is it faster but this bug has gone away. The bug definitely has something to do with xinerama.

Same issue on my side:
-----
Hi there,
I am running Ubuntu 8.10 on an x86 64 bit architecture without anz other OS hosted on it.
So, sometimes, my mouse decides to not respond to any clicking anymore: the system is still usable via keyb and the pointer is still there, movable, but I can not use the buttons anymore. There is not any specific event triggering this behaviour and this is happening to me with both a logitech and a microsoft mouse and both with a cable usb-attached one and a radio one.
This is also happening to me both in KDE and Gnome.. and without any specific application opened. I mean everytime it is happening in a different working situation.
-----
1 Nvidia card-2 monitors.

Adding another "me too". Two nvidia 8600 GT cards with four monitors on 8.10 with everything updated and using Xinerama. I generally run a couple instances of firefox, thunderbird, pidgin, intellij, and a couple of terminal sessions. It seems to usually happen when I'm entering or leaving either firefox or thunderbird. I'd be happy to provide any other information if needed.

Same issue here. Xinerama / KDE / Nividia 8800GT.

The "workaround" doesn't appear to work under KDE; however, trying the workaround _causes_ the bug to happen.

Haven't yet tried the downgrade of X, but will attempt. Please fix this soon, this is killing my productivity.

I'd like to post a positive feedback on the Twinview workaround for enviroments working with two monitors. I have adopted it 3 days ago, the problem has not happened anymore.

Please stop switching this to nvidia. If you read the thread you'll see that the problem happens for people with Matrox, ATI, etc.

@Reuben Firmin (and other fellow KDE users).

I found a work-around for us, but it's a pain and only works if you have both Gnome and KDE available on the system.

1: Switch to a text console (Control-Alt-F1) and login as your user.
2: Run "killall kwin" to kill the KDE Window manager.
3: Run "DISPLAY=:0.0 metacity" to run the Gnome window manager.
4: Switch back to the XWindows screen (Alt-F7), and follow the steps Kevin Browne posted to this thread on 2008-12-09.
5: Switch to the text console again, and press Ctrl-C to kill metacity.
6: Run "DISPLAY=:0.0 kwin" to run the KDE window manager again.
7: Switch back to the XWindows screen and you should be working again.

Now, can someone show me how to map Alt-Spacebar to the window pop-up screen like Gnome has?

Thanks,
Dan

This bug is affecting me also. Ubuntu 8.10. amd64. latest nvidia (177?). xinerama enabled quad-head. I was able to get out of it by pressing alt-f7 and clicking. i also confirm that xev wasn't processing any mouse events when moving the mouse around and clicking on the xev window.

root@timmy-desktop:~# lsusb
Bus 002 Device 005: ID 04fc:0c25 Sunplus Technology Co., Ltd
Bus 002 Device 004: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 04f9:0028 Brother Industries, Ltd Printer
Bus 001 Device 003: ID 046d:c043 Logitech, Inc. MX320 Laser Mouse
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

AutoAddDevices -> false and setting a udev macintosh emulation ignore .fig file didn't help.

Potentially fixed for me.

Upgraded to latest kernel 2.6.27-11-generic
Tried to install Latest Nvidia 180.22 but had hassles with kernel module so I removed using the nvidia install script
re-installed nvidia-glx-180 and nvidia-glx-180-dev
Also installed latest Xserver from repositories. (not the Hardy version, but Intrepid)

commented out Load "glx" from xorg.conf

No hanging, no crashes. Yet to try it with GLX turned on. However, I was having random freezes during gaming sessions with sauerbraten and warzone 2100, I can now play full screen (xinerama, 3 screens) with no hangs / freezes.

Will try with GLX extension turned on when I get a chance.

Nvidia 9500GT x 2
3 Screens.

Has anyone else been able to confirm what chimaster wrote? (with or without glx)

I finally got my box up, running, & stable with a downgraded X someone linked to above, but it's unfortunately slow as sin and I'm hoping maybe the newer drivers would provide better 2D support under Xinerama.

Ubuntu 8.10
2.6.27-9-generic
Xinerama 4-screens
Installed nvidia-glx-180
glx is enabled

With the upgrade of the video card drivers the freezing hasn't happened yet and the performance problems I was experiencing are mostly gone.

I'll let you know if I experience to freezing again.

Pascal R wrote:
> Has anyone else been able to confirm what chimaster wrote? (with or
> without glx)
>
> I finally got my box up, running, & stable with a downgraded X someone
> linked to above, but it's unfortunately slow as sin and I'm hoping maybe
> the newer drivers would provide better 2D support under Xinerama.
>
>
Slow as sin can be corrected. See:
http://www.nvnews.net/vbulletin/showthread.php?t=118088

bug duplicates:
https://bugs.launchpad.net/ubuntu/+bug/302392

Hi All!
I don't believe that GLX is the exact issue. I have a different machine that I described above, with an nVidia 8600 GT, and it only has two 1280x1024 monitors connected. I am running xinerama, and intrepid on that box as well, but I have never had the mouse lock up. Both machines that I use very regularly (one at work, the smaller one at home) have GLX enabled. The only difference in the xorg.confs of each machine is that the one affected by the bug has "Composite" "Enable" under the "Extensions" section. I don't believe this is a key trigger either, as other people who have posted, and are affected, do not have this option enabled.

After reading through this thread again, I am beginning to think that the bug is definitely performance related. It seams that I am able to manually trigger it by creating a heavy graphics load. I open several windows, mostly firefox, and also vmware workstation with a windows guest, and then grab a small firefox window and drag it around and across monitors as fast as I can. As long as I have many windows open that X has to re-draw when the window is dragged across them, the bug is triggered. If I do the same technique with an empty desktop, and one firefox window, I can not get it to happen.

All that being said, the article that WolphFang linked to explains the performance tweaks for the 177 drivers. It also mentions that those tweaks are the default settings for the 180 drivers, and may explain why people are having better luck with the 180 drivers. I will introduce the performance tweaks described in the article to my 177 drivers, and then report back my findings.

Thanks,
Travis Hegner

Hi,

I don't believe GLX is the issue either... I just didn't get a chance to switch it back on, will test further today. Performance is CRAP currently with 180 Drivers, I'll look into those tweaks added by default today also as I would like my screen to refresh.

I'm tentatively agreeing with load. I haven't been 100% stable with my suggestions above, when I run Virtualbox (with previously downgraded version of X it was ok) now it crashes after two changes in and out of the virtual window. I had 14 windows open last night doing some network work, Freemind, The Dude (Wine), OpenOffice, Virtual Box, Firefox and as soon as Virtualbox was used I crashed.

This really is getting frustrating though, every time it's tested it takes 2 hours out of our days. Anyways there is enough of us playing, hopefully one of us strikes gold or the maintainers find a solution.

Since my last post, I updated the performance settings and have not had the bug triggered since. I have also noticed a very significant 2d performance boost, which I have been very happy with. I can even run opengl games in windowed mode and the bug is no long triggered. This used to trigger the bug every single time. opengl apps in full screen still seem to have an issue, but the pretty much always have with xinerama. I've always just ran a secondary x server on one screen to run opengl apps.

If anyone would like any info or logs or anything from my machine... let me know...

Travis

Hi Travis,

Please post performance improvements that you implemented, I'd love to get a little more performance out of my Nvidia 9500GT. I can run games fine in Windowed mode, however, if I've been up and running for a while the performance gets a little choppy, if I restart X it settles down.

Nvidia 9500GT
AMD64
2.6.27-11-generic
nvidia-glx-180, -dev (180.11)

Still hanging when using virtualbox, no issues thus far with Flash and firefox, or other apps (aside from games getting choppy).

Cheers

GLX is not the cause of this problem. I disabled it in my configuration weeks ago and still encounter this problem daily.

Based on reports here and in other bug trackers, and my own experience with this problem, I agree that it is most likely related to load in some way. Xinerama itself can be rather resource intensive, and the 2D performance of the Nvidia drivers is notoriously poor. This probably accounts for the fact that it is most often Nvidia users who report this problem, and that upgrading to a newer, better performing driver appears to 'fix' the problem.

The upstream report at http://bugs.freedesktop.org/show_bug.cgi?id=18668 (previously linked by Thomas Jarosch) suggests a problem with animated cursors may be at the root of this. This may be worth testing, if anybody has the time and inclination.

On Fri, Jan 16, 2009 at 1:48 PM, chimaster <email address hidden> wrote:

> Please post performance improvements that you implemented, I'd love to
> get a little more performance out of my Nvidia 9500GT.

Lets keep this trouble ticket on track and not post speed improvments.

Travis: Can you tell us if you're using the Ubuntu supplied restricted
NVidia binaries, or if you downloaded the install image from NVidia and
installed manually.

Thanks,

Dan

--
"Quis custodiet ipsos custodes?" (Who can watch the watchmen?) -- from the
Satires of Juvenal
"I do not fear computers, I fear the lack of them." -- Isaac Asimov (Author)
** *** ***** ******* *********** *************

Chimaster,

The performance tweaks are located here: http://www.nvnews.net/vbulletin/showthread.php?t=118088. I believe these are geared for improving 2d performance, so running games, you may not see a benefit. The article also mentions that the 180 drivers already have these settings by default, so you may already be covered.

Dan,

Yes, I am running the ubuntu restricted drivers package for 177.

:-(

I have 3 monitors, 1 rotated, and using Xinerama to get single desktop, cards are 2x8600GT nvidia, running ubuntu 8.10 with the nvidia 180.22 drivers.

I have identical work and home machines, at home I was getting the problem every couple of hours, at work i changed from a wireless mouse to a usb cable attached one, and the problem is mitigated to about once a day. It is still a complete nightmare to have to close all my work and restart X.

seems this issue should be getting some higher profile, as it essentially makes Intrepid a completely useless platform for triple monitor users (8.04 had horrid performance so i never migrated to that)

I can confirm the mtopro workaround re-attaches the mouse to X on my system.

Well I'm still experiencing the problem with the nvidia-glx-180 drivers.
The upstream bug report (https://bugs.freedesktop.org/show_bug.cgi?id=18668) said something about it maybe being due to the use of animated cursors.
I tried to test this out by installing a cursor theme without animations, but I could not find any.
Let me know if anyone tests that theory.

Well I've came up with a decent workaround (at least i think so), you can force the mouse and xserver back in sync by using a simple command from the xautomation package. simply forcing the mouse pos to the origin of the desktop forces them back in sync.

I've written up a short guide http://www.gen-x-design.com/archives/workaround-for-ubuntu-810-mouse-bug/ that shows the steps and how to wire it into a single keypress under gnome. This means when the mouse locks the fix is simply hitting a single key combo.

This has moved the problem to a minor annoyance for me.

it should be easy enough, to adapt this to other setups.

Geekfreak's fix makes me wonder if the cause is related to cursor position.

One of the common triggers mentioned by folks on this thread is virtual machines or virtual desktop software such as vnc, synergy, and vmware. Those often work by moving the mouse pointer offscreen (for example, when you use synergy to control a remote desktop, the pointer is hidden on the local desktop by moving it to a point outside of view).

Can anyone reliably trigger the bug by using a similar xautomation command to move the pointer to a location offscreen?

tried 'xte mousemove 4000 4000' the pointer disappears but comes back as soon as I move it.

not conclusive, but i couldn't force the problem using this technique.

I can confirm that geekfreak's workaround works. Very nice!

I can force the issue by forcing it to the edge of each screen one after the other:

Here's a shell script that'll do it, assuming your screens are 1680 wide (the first column on screen 0 is 0, so the last column on that screen is 1679.)

---------------------------
#!/bin/bash

xte "mousemove 1679 5"
xte "mousemove 1680 5"
---------------------------

geekfreak. thank you for your efforts in documenting a fix. I have it ready for the next time and it sounds much easier! I have not had as many issues as long as I don't copy from one screen and paste to the other. I try to limit the carrying any data across screens and it has helped a lot as well.

When implementing geekfreak's idea on my machine I came across an issue that I have not paid much attention to in the past but this could be linked.

When typing 'gconf-editor' in terminal, it opens fine, however I get an error in terminal as follows:
Xlib: extension "RANDR" missing on display ":0.0".

This can also be duplicated with xrandr -v.

Google searches show this is a common error when upgrading from 8.04 to 8.10. In fact the first computer I tried 8.10 on, failed to install due to the RANDR extension. This computer is freshly installed but has the same file issue apparently.

Does anyone else have the same issue, or think it could be linked to this issue?

Awsome, Reuben's script can 100% force the error. my script can 100% fix it, I think this means we are near the end, as if the problem is easily reproducible it should be easily debuggable/fixable.

good thinking Tessa, good work Reubin.

now how about getting the darn problem fixed core dudes ;-)

I hadn't had the problem show up for a couple of days, and though maybe a recent update had fixed something, but as Reuben's script show the issue is very much alive.

The RANDR missing error may be the problem, you get this because it's not supported in xinerama, I was just ignoring it (doh!) but I definately see the issue moving from the GPU0-GPU1 boundary which just happens to be onto or off of my rotated screen. i think everyone with the triple monitor/xinerama combo will see that when opening X apps. I see it every time i gedit a file for example.

So maybe this will end up being an 'unsupported configuration' but at least we can now unlock with ease.

Interesting, using Reubens approach i can break it moving the mouse to the first pixel on the last screen

xte "mousemove 2880 5"

I'm assuming here my config of 1280x1024,1600x1200,1024x1280 results in 2880 being the first column of pixels on the last screen (as the count starts at 0, the rightmost pixel is resolution-1)

My screen resolution is 1280x1024 (on each of 4 monitors)

If I do:

xte "mousemove 1279 5" && xte "mousemove 1280 5"

it breaks the mouse every time
to get it back, I need to do an xte mousemove which relocates the cursor on the "first" display.

for me, xte "mousemove 800 800" always fixes it.

Well Reuben's break is confirmed for my system. However geekfreak's fix will not work for me.

The only fix found on two screens with different resolutions, is to 'alt+tab' to a window on screen 1. Attempt to move that window on screen 1 with 'alt+F7'. This first attempt fails, so I alt+tab back to screen 0 (primary display) and alt+F7 to move a window and the mouse click will start working again.

It does seem RANDR is linked and the cause of some deeper issues in 8.10 that was non-existant in 8.04.

Will post again when I find a 'mousemove' number that works.

Actually, my mousemove doesn't work if any application is already on the primary monitor.

a double xte "mousemove" moving the cursor to an "off the primary, onto the primary" works.

For example, "xte mousemove 1300 1300" && xte mousemove "800 800" fixes it.

Rob

Robstarusa, that seems to do the trick for me as well. Moving anywhere on secondary display then back to the primary display.

The quotes were also part of why it wouldn't work for me. If you try this make sure there are quotes around the command similar to this:
-----------------

xte "mousemove 1980 0"
xte "mousemove 0 0"

-----------------

maybe the fix is to force move the mouse from a different screen to the primary, i'm usually on the second or third screen when it happens, and my script pushes it to the first.

I've just confirmed, if my mouse is displayed on the first screen and i break it, it mousemouse 0 0 wont fix it, but moving the mouse to the second screen and mousemove 0 0 will fix it.

sounds to me like there is different code being executed if the mouse is on the current screen (which makes perfect sense) and you need to force X to move the mouse to a different screen.

so it may just be as simple as moving the mouse to a different screen.

this jives with my initial investigation as originally i wanted to have the hotkey center the mouse in the display but this didn't work (no doubt as my cursor was on that screen when I tried).

so that would make the current fix

either
 change the script to move the mouse to two screens.
or
 just move the mouse to the other screen before hitting the hotkey.

i'd be interested to know if those can be shown as a consistent fix. and i'll update my blog post.

confirmed geekfreak. your original fix works as long as the mouse is moved to a secondary display before running the script, even if the mouse 'breaks' in the primary display. I was working off the primary display when running the script and thus the original fix did not work. To me it is easier to add a line to the script instead of moving the mouse across before executing, but just personal preference. Thanks again for the patch, this will def make life easier.

Hm, a lot of people here is talking about this bug being a problem with dual card setups. I'm having this problem with single card, dual head setup. Two screens and xinerama. Two card setup I can't even get to work. I'm using latest ubuntu nvidia driver and I have 8800 GTS and 7800 GT card. If I run Xorg with -config parameter where I use three screens all works fine. But if I run xinit with the same config, then xinit will segfault.

I don't think animated cursors are the cause. I installed and switched to a non-animated cursor theme, and the problem still occurs with roughly the same frequency.

If I read it correctly, the upstream bug report suggests that the problem occurs where the system needs to update the cursor image, but the cursor crosses the boundary from one screen to another before the update can occur. I suspect that any change of cursor image, not just cursor animation, invokes the same function calls, and is likely to trigger the bug.

I most often encounter the problem when using a Windows application running under WINE, then moving the cursor to another screen. When the cursor is over the WINE application its image switches to a Windows-like pointer (the app doesn't even need to have focus for this to happen). I suspect that when the system is under heavy load, and I move the cursor off the WINE app, a call is made to update the cursor image to the regular X pointer but by the time the call executes the cursor has already crossed the screen boundary, triggering the bug.

A similar change in cursor image occurs with VirtualBox and VNC (again, the window doesn't need to have focus), which may account for the number of VM and VNC users encountering this problem.

Of course, as I'm not familiar with the internals of X, this is all only a guess.

I've been doing more debugging. First, I couldn't find any jumps between the two screens that _won't_ cause the mouse "detachment". For example (assuming screen width of 1680):

------------
#!/bin/bash

xte "mousemove 1479 5"
xte "mousemove 1900 5"
------------

------------
#!/bin/bash

xte "mousemove 1200 5"
xte "mousemove 2100 5"
------------

Also, this (apparently) isn't time related. Making sure not to move your mouse, try (again, adjusted for your resolution):

------------
#!/bin/bash

xte "mousemove 1200 5"
sleep 1
xte "mousemove 2100 5"
-------------

After messing with that, I was curious about where the cursor ostensibly was during "detachment". So, I dug around for applications to detect the cursor position and found a QT3 script on some forum, which I've attached. I don't know if this will work for everybody on Gnome, but it works under KDE4 and I assume also under KDE3. (See readme.txt in the zip).

The upshot: the cursor is registered as being stuck at 0,0 during "detachment"; despite me seeing the cursor moving on screen, the coordinates stay registered as being at 0,0.

Nice work narrowing this down everyone!

I wanted to comment that even though I can no longer trigger the bug through "normal" usage (with the exception of opengl games), I CAN still trigger the bug with the xte "mousemove" commands. As is true for everyone else, You must move the cursor off of the screen you jump to in order to trigger the bug, and to re-sync the cursor, you must move it off of screen 0, then 'jump' it somewhere on to screen 0.

I have also noticed that when the mouse becomes disconnected by jumping it to another screen, the cursor goes where I initially put it, but when I begin moving it from it's new location, it jumps itself to the coordinates on the new screen, which were the coordinates on the old screen before I manually jumped it. I hope that makes sense.

For Instance:
I (manually) move the cursor to 1670, 1000 on screen1, then run xte to jump it to -1000, 10 (which is roughly 680, 10 on screen2). The cursor shows up at the coordinates that I told xte to put it, but when I begin to move the mouse, it jumps again on it's own to 1670, 1000 on screen2, and the bug is triggered. Now if I run xte to jump it to 10, 10 on screen0, it goes there, and when I begin to move the mouse, it jumps on it's own back to 1670, 1000 on screen0, and the cursor is restored to normal.

It seems that somewhere a function is not updating the new location information of the cursor, and the program with the old location is not multi-screen aware, it only knows the relative coordinates at "this" screen and puts the cursor back to that location when called. So long as the cursor doesn't leave the screen with a jump, the bug is not triggered.

Another oddity about my system, which is perhaps normal as I've never used xte before, my server layout is:
Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0" 1680 0
    Screen 1 "Screen1" 3360 0
    Screen 2 "Screen2" 0 0
    Screen 3 "Screen3" 5040 13
    InputDevice "Keyboard0" "CoreKeyboard"
    InputDevice "Mouse0" "CorePointer"
EndSection
(I have added a fourth screen to my original specs way, way above)
so you would expect xte "mousemove 1680 0" to put the cursor at upper left on screen0 but it does not. xte says 0, 0 is at upper left on screen0, and screen2's (left of screen0) upper left is at -1680, 0. This may be normal, i don't know.

Thanks again everyone!

Potentially use information when attempting to implement the "FIX":

My shell script:

<------------------
#!/bin/sh

ORIG="$(xmousepos | cut -f 1,2 -d ' ')"
xte "mousemove 4000 4000"
xte "mousemove $ORIG"
<------------------

Instead of xmousepos returning mouse coordinates after the bug has been
triggered, I instead get:

mjoyner@mjoyner-x64b:~$ fix
X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 38 (X_QueryPointer)
  Resource id in failed request: 0x0
  Serial number of failed request: 8
  Current serial number in output stream: 8

Updated fix script:

#!/bin/sh

ORIG="$(xmousepos 2> /dev/null | cut -f 1,2 -d ' ')"
xte "mousemove -1 -1"
if [ x"$ORIG" = x"" ]; then ORIG="0 0"; fi
xte "mousemove $ORIG"

On Fri, Jan 23, 2009 at 9:45 AM, Michael Joyner <email address hidden>wrote:

>
> Potentially use information when attempting to implement the "FIX":
>
> My shell script:
>
>
> <------------------
> #!/bin/sh
>
> ORIG="$(xmousepos | cut -f 1,2 -d ' ')"
> xte "mousemove 4000 4000"
> xte "mousemove $ORIG"
> <------------------
>
> Instead of xmousepos returning mouse coordinates after the bug has been
> triggered, I instead get:
>
> mjoyner@mjoyner-x64b:~$ fix
> X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 38 (X_QueryPointer)
> Resource id in failed request: 0x0
> Serial number of failed request: 8
> Current serial number in output stream: 8
>
>
>
>

I didn't know about xmousepos; good find. Confirmed:

reubenf@fridge:~$ ~/xbug
reubenf@fridge:~$ xmousepos
X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 38 (X_QueryPointer)
  Resource id in failed request: 0x0
  Serial number of failed request: 8
  Current serial number in output stream: 8
reubenf@fridge:~$ ~/resetmouse
reubenf@fridge:~$ xmousepos
687 621 442 562

That error may just indicate a generic xmousepos error, for example I get a very similar message with an invalid param to xmousepos.

davey@cylon:$ xmousepos --help
X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 38 (X_QueryPointer)
  Resource id in failed request: 0xa
  Serial number of failed request: 7
  Current serial number in output stream: 7

this might be interesting a perhaps we could use it to have a cron job doing an xmousepos every second and autofixing the pointer if an error is reported, although I'm happy enough with the mousefix script attached to a hotkey.

KDE 4.2 seems to prevent the xte / reset workaround from succeeding. I have a powerful machine (quad CPU, plenty of memory, good GPU) so it's not as if things should be overloaded by the UI; and yet, running firefox / amarok / eclipse is enough to cause frequent occurrences of this bug that cannot be xte'd around.

There was a patch submitted upstream which may fix the issue. See https://bugs.freedesktop.org/show_bug.cgi?id=18668

Very happy to see this. I poked that bug to SEVERE last week, and it got pulled from the group queue and assigned to a dev, the work from this thread to make it reproducible seems to have helped.

So hopefully we'll see an update soon and the problem will be gone!

awsome.

for those that are comfortable with building the patched server

http://bugs.freedesktop.org/show_bug.cgi?id=18668

--- Comment #30 from Peter Hutterer <email address hidden> 2009-01-29 22:34:20 PST ---
Fedora 10 users can get a scratch build, see
https://bugzilla.redhat.com/show_bug.cgi?id=473825#c35

Otherwise, you need to get the server sources from your respective distribution
and apply the patch (or get your distribution to do it for you). Then build and
install the patched server.
Alternatively you can check out the git repository, more on
http://wiki.x.org/wiki/JhBuildInstructions

Hi all, I've got this same problem also - although, from reading through all of these posts, have the (temporary) work around for it. It's fairly simply and can get you back up and running with in a few seconds. When ever it occurs (I've noticed that heavy graphics use will trigger it easily, although I've triggered it with just Firefox and terminals open), simply hit ALT-F7 (or ALT-SPACE and with cursor keys scroll down to move) - this is for moving the active window. If it doesn't move via the mouse cursor (it should) use the cursor keys - move the window from one desktop to the other and back - and whala! mouse back and functional! (after you stop moving the window of course) :-) Many thanks for Mr Kevin Browne who figured out the way around this annoying bug ;-)

ditto. Nvidia card, dual displays... the mouse issue. switch to twinview from xinerama and no problems yet. would rather use xinerama.

trouble shooting mouse files (as described here: https://wiki.ubuntu.com/DebuggingMouseDetection) attached should they be helpful...

Okay, I don't think we need anymore "Hey, I have this problem too!" posts. This bug has been fixed. You need to upgrade your Xorg Server and associated files. At least that's what I did with my Fedora 10 system. Bug is gone, working perfectly with two Nvidia dual-head cards with 180.22 drivers and four monitors in Xinerama. Thank you to all who have contributed.

messinwu: sorry. Im a bit green... I thought one of the big advantages of such a large open source community was the diversity in testing and reporting of the user experience. It took me a few min to gather the info as directed on the wiki page... I didnt do it for my own self satisfaction - I truly thought this type of participation was/could be helpful.

Its not as though all of these "this problem too" posters filed separate bug reports. I think we just wanted to help in any way we can. It was from several of these such post that I found my workaround via twin veiw, otherwise i was going back to 8.04.... Thanks for the help everyone.

What version of Xorg ?
Using UBUNTU, still have bug with latest updates.

messinwu wrote:
> Okay, I don't think we need anymore "Hey, I have this problem too!"
> posts. This bug has been fixed. You need to upgrade your Xorg Server
> and associated files. At least that's what I did with my Fedora 10
> system. Bug is gone, working perfectly with two Nvidia dual-head cards
> with 180.22 drivers and four monitors in Xinerama. Thank you to all who
> have contributed.
>
>

messinwu, I'm still buggin too. Can you please validate your "fixed" with references to versions that you are using include Xorg. Bearing in mind of course that Ubuntu might not be using the same versions / patches / time frames as Fedora.

P.S. Me Too, and this problem sucks. The more the better, if it wasn't for so many me too's then we'd all probably still be saying this is an Nvidia specific issue and not related to Xinerama or Xorg.

The latest patch is probably not in the Ubuntu updates yet. You have to patch your Xorg server, as suggested in Post #130 of this thread. Unfortunately, I have Fedora 10 and not Ubuntu, so my upgrade was simpler because they already had .rpm's made for the new Xorg that I installed with yum. If someone else has done this with Ubuntu already, please chime in and help those folks out. I'm guessing you just download the patched source code and compile it and install it as root... ?

X -version

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.18.el5 i686
Current Operating System: Linux localhost.localdomain 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST 2009 i686
Build Date: 29 January 2009 08:40:04PM
Build ID: xorg-x11-server 1.5.3-10.fc10
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.

I got the latest rpm's from the link from post #35 of the following thread:
https://bugzilla.redhat.com/show_bug.cgi?id=473825#c35

If you follow that thread, the specific cause of the problem was identified and fixed with the latest patch. A simple 'yum update' will not do it, I had to download and manually install the 'i386' rpm's from the link above.

Can someone extract the fedora patch? Perhaps this is a dupe of 41301, of which a patch was just uploaded to jaunty.

Is there any ETA for when this fix is going to get into the normal Ubuntu update channels? Patching/recompiling X isn't really an option for some of us.

FWIW, I switched to Twinview and (obviously) the problem hasn't reoccurred. I had an aversion to Twinview in the past (based on instability last time I tried it, years ago, I think) but it's stable (and, bonus, gives me full KDE4 bling, which xinerama was somehow blocking.)

Unfortunately "TwinView" doesn't work for those of us with three+ monitors ("TripletView" anyone?).

Dan

(Or am I missing something with TwinView to make it work with my two NVidia cards -- GeForce 8600 GT, and older GeForce2 MX/MX 400? I'm using the NVidia driver for the 8600, and the opensource "nv" driver for the 400 IIRC...)

> Unfortunately "TwinView" doesn't work for those of us with three+ monitors ("TripletView" anyone?).
Or just one monitor...

This should classify for a SRU, in my humble opinion.

> Is there any ETA for when this fix is going to get into the normal Ubuntu update channels?

No ETA until there is a patch identified and tested in Jaunty. So if anyone is anxious to see this fixed, you can help by extracting the patch from the fedora package (I poked around but didn't spot it offhand.)

> This should classify for a SRU, in my humble opinion.

If you'd like to see it as an SRU, you can lay the groundwork by updating the description of this bug and fill in the information specified in the procedure https://wiki.ubuntu.com/StableReleaseUpdates . If this is done, and a regression-free patch is identified and validated on Jaunty, I wouldn't be opposed to putting in an SRU on it.

This seems to be http://bugs.freedesktop.org/show_bug.cgi?id=18668
Both this LP bug and the Redhat bug are referenced in that bug.
Fix was pushed as 9fe9b6e4ef669b192ee349e3290db5d2aeea273c and nominated for 1.6
Steven Harms reports the fix works on Intrepid.

I patched xorg-server with patch from http://bugs.freedesktop.org/show_bug.cgi?id=18668

You can find updated xorg packages in my PPA, while ubuntu developers update official package.
https://launchpad.net/~m0sia/+archive/ppa

After patching xserver with the patch from http://bugs.freedesktop.org/show_bug.cgi?id=18668 we have had no further problems.

We are using TwinView across 3 monitors (2 GPUs). xorg.conf attached.