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

[Pascal R]

[Problem]
When using Xinerama (such as with multiple video cards), if using an animated cursor, after some time X will stop responding to mouse events. All mouse events are being sent to the root window instead of client applications.

[SRU]
Confirmed fix is released upstream in xserver 1.6.0 and present in Jaunty (as of xserver 1.6.0)

Impact: Severe regression for users of -nvidia and other drivers which still rely on Xinerama, resulting in mouse cursor (and thus much of the GUI) becoming unusable. No reliable workaround known.

Fix: Avoid calling UpdateSpriteForScreen() if the Xinerama extension is loaded

Patch: https://bugs.freedesktop.org/attachment.cgi?id=22373

Test Case: Configure a Xinerama multi-head (3+) layout using -nvidia. Configure the mouse to use an animated cursor; this is optional but makes it easier to reproduce the problem. Move windows around, from one screen to another until the bug is triggered (may take a few tries). Mouse clicking will become disabled, while keyboard and mouse movement continues to work correctly.

Regression Potential: The fix is extremely trivial and highly tied to Xinerama. The net effect is to prevent code from being executed rather than enable it. For non-Xinerama users, there is no chance for regression. For Xinerama users, give the huge number that have reported this as an issue, this bug probably affects all users; furthermore we already have numerous confirmations of the fix and zero reports of side effects. So I think the chance of regression is close to nil.

[Original Report]
After upgrading to Ibex a problem has appeared where after some activity (10-15 minutes), X will suddenly stop responding to any mouse events - the cursor is still there and will move around, but windows won't change focus and clicking the mouse buttons have no effect (in both the focused and unfocused windows). Keyboard still works fine and I can Alt-Tab between windows. Mouse still moves the cursor normally, just will not click anything.

I have a four-monitor Xinerama setup running the latest NVidia drivers on two 8600GT Graphics cards. This setup worked perfectly in Hardy.

Problem is present in 2.6.27-7 & 2.6.24-19, Nvidia Drivers 177 & 173.

Tried with two different wired optical mouses (logitech and microsoft) and problem is present in both.

Once the problem occurs, the only way to get the mouse buttons working again is to Ctl-Alt-Backspace to restart X. Mouse will work fine for a period of time after that.

Strangely - if I have xev running, it won't respond to any events if the mouse is over the window, but if the cursor is at the same height as the window one screen over to the right, it will show events.

I don't think I see anything in dmesg / syslog / Xorg.conf.

amd64 arch w/ 8 GB Ram.

This is driving me absolutely crazy as my computer is pretty much unusable.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: xorg 1:7.4~5ubuntu3
ProcEnviron:
 SHELL=/bin/bash
 PATH=/home/User Name/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/User Name/bin
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.27-7-generic (buildd@crested) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Tue Nov 4 19:33:06 UTC 2008

SourcePackage: xorg
Uname: Linux 2.6.27-7-generic x86_64
Xrandr:

xkbcomp:

[lspci]
00:00.0 Host bridge [0600]: nVidia Corporation C55 Host Bridge [10de:03a1] (rev a2)
     Subsystem: nVidia Corporation Device [10de:c55e]
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 8600 GTS [10de:0400] (rev a1)
     Subsystem: eVga.com. Corp. Device [3842:c773]
03:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 8600 GTS [10de:0400] (rev a1)
     Subsystem: eVga.com. Corp. Device [3842:c773]

[Tim Cole (timothy-j-cole)]

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.

[Pascal R (pascal-cykod)]

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

[Luc (luc-santeramo)]

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.

[Zach (zivester)]

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.

[Pascal R (pascal-cykod)]

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.

[ThomasAdam (thomas-adam22)]

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

-- Thomas Adam

[Zach (zivester)]

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.

[Luc (luc-santeramo)]

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.

[Walter White (walterjwhite)]

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.

[Zach (zivester)]

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.

[rooijan (rrossouw)]

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.

[Pascal R (pascal-cykod)]

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

[Travis Hegner (thegner)]

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.

[rooijan (rrossouw)]

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.

[Zach (zivester)]

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

[Zach (zivester)]

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.

[Zach (zivester)]

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

[Travis Hegner (thegner)]

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.

[Pascal R (pascal-cykod)]

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

[Travis Hegner (thegner)]

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.

[MetraDynamix (c-admin-dedicatedlayer-com)]

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

[Travis Hegner (thegner)]

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.

[Nelson (nrescobar+lp)]

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.

[Daniel Hopkins (drhops)]

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!

[Peter Leonard (pete-peteleonard)]

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.

[Peter Leonard (pete-peteleonard)]

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.

[Zaai (zaai)]

Anywhere between a few minutes and a few hours, the mouse buttons stop responding. The mouse itself keeps moving and remains visible.

The trigger is when moving the mouse between two xinerama screens.
No messages about this are logged in Xorg.0.log, messages, or any other log file.
In this state xev does not see any mouse events.

When X is restarted the mouse buttons are recognized again.
Another recovery is running a synergy server locally and connecting to it with the client. Note that this only works when running synergyc from the konsole in one of the xinerama screens. Doing the exact same thing in the other screen has no effect.

OS: Gentoo
xorg-7.4; xorg-server-1.5.2

The bug was first reported by Eric Stein. See also: https://bugs.gentoo.org/show_bug.cgi?id=243496 for more details.

[Randy Wilson (blazerw)]

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.

[Travis Hegner (thegner)]

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.

[Robstarusa (rob-naseca)]

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.

[Robstarusa (rob-naseca)]

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.

[Nelson (nrescobar+lp)]

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.

[xianthax (xianthax)]

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

[JPHein (jp-jphein)]

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.

[Matt Cockayne (matt-cockayne)]

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"

[Peter Leonard (pete-peteleonard)]

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.

[Peter Hutterer (peter-hutterer)]

On Sat, Nov 22, 2008 at 06:50:16PM -0800, <email address hidden> wrote:
> Anywhere between a few minutes and a few hours, the mouse buttons stop
> responding. The mouse itself keeps moving and remains visible.

> The trigger is when moving the mouse between two xinerama screens.

just a guess, could it be that the button events are delivered to the wrong
screen? If you have a full-screen xev on the other screen when it happens,
does it show the button events.

[Zaai (zaai)]

Good suggestion, but thats not it unfortunately.

Running xev in both screens. Neither reports any events when moving or clicking the mouse buttons onto the xev area.

[Edward (edward-redhat-bugs)]

OK, I deleted the mouse and keyboard sections, whole, from /etc/X11/xorg.conf,
as well as references to them. I logged out and back in to restart X. Most
everything appears to work as it did before. However, now I cannot configure
my Synaptics touchpad. I bring up System -> Preferences -> Hardware ->
Touchpad and I get a pop-up complaint

GSynaptics couldn't initialize.
You have to set 'SHMConfig' 'true' in xorg.conf or XF86Config to use GSynaptics

Either the SHM line does something or GSynaptics has an intermittent failure to
operate. My experience says it could be either one.

Oddly, I was seeing this issue regularly, one or more times every day, until I reported the bug. I haven't seen it since. But I'm positive it will recur. When it does, I'll run the requested tests and gather the requested logs. Hopefully Robert will be able to reproduce this.

[Peter (peter-redhat-bugs)]

Do you still have the Synaptics line in your config? If not, add the line
<merge key="input.x11_options.SHMConfig" type="string">1</merge> to
 /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi

Try the command synclient -l. Does that report an error too? If so, then I need to see your log file.

[Edward (edward-redhat-bugs)]

I totally removed the keyboard and mouse sections from xorg.conf, meaning there is no reference at all to Synaptics.

$ synclient -l
Can't access shared memory area. SHMConfig disabled?

I've updated 10-synaptics.fdi so it now contains

      <match key="info.product" contains="AlpsPS/2 ALPS">
 <merge key="input.x11_driver" type="string">synaptics</merge>
 <merge key="input.x11_options.SHMConfig" type="string">1</merge>
      </match>

I'll let you know if this helps.

[Robert (robert-redhat-bugs-1)]

Just an FYI--

I'm trying to recreate the problem now, but of course, it won't when
I most need it to. I'll let you know the results of evtest as soon
as the problem recreates. Unfortunately, that particular system won't
get a lot of use until probably Monday.

[Edward (edward-redhat-bugs)]

Updating 10-synaptics.fdi does allow me to run synclient. I only updated the one XML stanza that matches my touchpad, but probably all synaptics products need this setting?

[Peter (peter-redhat-bugs)]

Edward:
Just a heads-up, I had debugging session with Robert and we couldn't identify the issue yet. But here's a few things I'd need from you:

- are you on a 64 bit box?
- please get http://people.freedesktop.org/~whot/grabtest.c, compile it with gcc -o grabtest -lX11 grabtest.c and run it when the mouse is stuck. Does it report success for both mouse and keyboard?
- does xev show anything (movements, button events) when the mouse is stuck?
- does evtest show events when the mouse is stuck in X?

I'm waiting on a rather special logfile from Robert now, but the above information will help figuring out whether you two see the same issue.

[Edward (edward-redhat-bugs)]

I am not on a 64 bit platform. It's a Core 2 Duo with Fedora 10 x86 installed.

If I run xev when things are OK, I only get events when the mouse moves over the pop-up window. I'll try this the next time the mouse freezes, but if I cannot get the window moved under where the mouse is, it may not do much good.

grabtest when all is well successfully grabs both keyboard and mouse, of course.

Next time things freeze up, I'll thy the things mentioned here.

[Robert (robert-redhat-bugs-1)]

I recreated the problem, then tried variations of:

xmond -verbose 4 -server :0 -port 4
xev

The xmond program seemed to receive nothing from any mouse clicks.
When I <ctrl-c> out of xmond, the resulting file is 0 length.
Also, when I run it interactively, it produces no output on the screen.
Either it's getting nothing or I'm doing something wrong.

[Peter (peter-redhat-bugs)]

(In reply to comment #16)
> I recreated the problem, then tried variations of:
>
> xmond -verbose 4 -server :0 -port 4
> xev

Just for the archives (we already talked about that over IRC):
you need to run xev through the new display provided by xmond, i.e. DISPLAY=localhost:4 xev

Edward:
Some handy shortcuts we figured out today:
Alt+F7 is GNOME's default shortcut for move window.
Alt+F10 for maximise window.

Do you have a multi-monitor setup too? That seems to be Robert's issue. If you do, try moving the xev window around between the monitors and mouse functionality comes back at some point. Robert will post more detailed information on that soon.

[Robert (robert-redhat-bugs-1)]

First, here is a detailed description of how to recreate the failure,
at least in my case:

You need to have more than one monitor. I'm running xinerama so my
desktop is spanning between multiple monitors. Also, I believe you
need to have auto-raise set on (no proof of this). To set it on, do:
System->Preferences->Look and Feel->Windows, then check the box that
indicates "Select windows when the mouse moves over them". Also, set
a half-second delay, so check the box next to "Raise selected windows
after an interval", and an interval value of 0.5 seconds.
Next, open a few windows on each monitor. Then move your mouse cursor
back and forth a few times between the two monitors, briefly highlighting
the windows on each monitor.

Peter's description of the problem from a debug session earlier today:
"The server thinks that the sprite window is the root window, so it's
trying to deliver all events to the root window."

The Sprite window is the window underneath your mouse cursor. The root
window is the very first grey window, the initial one with "X" displayed
when x is starting.

My theory as to what's going on:
Suppose I have monitor #1 and monitor #2. Suppose I open a window on
monitor #2. When I move my mouse cursor over the window, the auto-raise
timer of 0.5 seconds starts ticking. During that time, I move my
mouse cursor to the other monitor. After 0.5 seconds, auto-raise
tries to raise the window I last hovered over. However, when it does,
the mouse cursor has been repositioned to monitor #1. In other words,
there is no more sprite window because the mouse cursor is on a
different monitor. So X loses track of the sprite window which appears
only on monitor #2. Unable to find a valid sprite window, it defaults
back to the root window. The root window cannot handle the mouse click
events, so they are ignored. This is just my theory.

We did find a viable circumvention:
If you encounter this problem, use the keyboard to navigate around
the screen. Use <alt><tab> to switch between windows. Once you've
gotten to a window, use <alt><F7> to move the window from one monitor
to the next. Then move it back again. This seems to allow X to
re-sync its sprite window and mouse clicks are then processed correctly.

[Robert (robert-redhat-bugs-1)]

Other possible circumventions:

1. Don't use auto-raise.
2. Don't use a delay for auto-raise (set value to 0)
3. Don't move your cursor until your windows are fully brought
   to the foreground.

[Edward (edward-redhat-bugs)]

I don't have multiple monitors. This is a laptop to which I have never (so far) connected an external monitor. However, I do use auto-raise with an interval of 2 seconds. With this clue, next time this happens I'll pay attention to what I was doing immediately before the mouse freezes.

[Edward (edward-redhat-bugs)]

Hmm, my mouse just froze for the first time in a while. I was able to use keyboard shortcuts to start Firefox. But something about the process of navigating to this web site to get the full list of "to do" items woke the mouse up again. I'll have to try next time, but wanted to put a note that my mouse finally froze up again, for a good part of a minute, while the keyboard and rest of the system were responsive.

[Edward (edward-redhat-bugs)]

Ah, THIS time, /var/log/messages and dmesg have the following messages:

psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.
psmouse.c: resync failed, issuing reconnect request

This may be a different failure than what I've seen before, as /var/log/messages.* files don't have other occurrences of the above text.

[Peter (peter-redhat-bugs)]

Adding upstream bug reference.

Edward: please run xdpyinfo | grep root to get the the root window ID, then run xev -id <root id> when the problem occurs. Do you see events?

(In reply to comment #22)
> psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3
> bytes away.
> psmouse.c: resync failed, issuing reconnect request

If that happens, the mouse should only stop for a second or so and then come back (unless it never came back of course).

[Edward (edward-redhat-bugs)]

OK, I finally reproduced the problem, but the behavior was a little different from before. From when I booted up, the mouse failed to do anything. xev gave nothing. Looking at /proc/bus/input/devices, I noticed that my two mouse devices were missing, and everything else was identical except for a few device numbers that of course changed with a few devices in the middle going away. The following devices went missing:

I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="PS/2 Mouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=6337
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse2 event6
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

I'll attach my demsg of my original boot tonight (where the mouse device was absent) and my 2nd boot tonight (where the mouse works as it should). Unlike before, nothing could fix the problem, including going to a console and then back to X, logging out and back in, killing X with Ctrl-Alt-Backspace. The only thing that helped was rebooting.

[Peter (peter-redhat-bugs)]

That would indicate that you have a very different problem than Robert, and chances are that it's kernel in your case.
Do you mind cloning the bug and attach your xorg.log (next time it breaks) and dmesg to the cloned bug? Let's leave this one for the multi-screen problem. Thanks.

[Edward (edward-redhat-bugs)]

Created attachment 327058
dmesg from bootup where the mouse was non-responsive

[Edward (edward-redhat-bugs)]

Created attachment 327059
dmesg from bootup where the mouse was responsive and normal

[Peter (peter-redhat-bugs)]

*** Bug 475945 has been marked as a duplicate of this bug. ***

[Robert (robert-redhat-bugs-1)]

Peter and I worked on this problem some more.

My configuration is proprietary nvidia driver, two GEForce cards
and three screens (screen0=card0,0. screen1=card0,1. screen2=card1,0.)
All screens are running at 1280x1024 resolution, and I've got xinarama.

I can recreate the problem easily by dragging my mouse from screen1 to
screen2, which spans between the two nvidia cards. During a gdb
debugging session, during which every slowed down, my mouse cursor
intermittently jumped from its current location (call it x,y) on screen1
to the same (x,y) on screen2, and back.

I tried to recreate the problem between screen0 and screen1 (staying
within the same video card) and was unable. However, this morning the
problem recreated "by accident" between screen0 and screen1, and my
mouse cursor was no where near screen2. So the problem is easily
recreated when switching between card screens and difficult (but still
possible) to recreate when switching between screens on the same card.

Yesterday, I was able to recreate the problem, even with auto-raise
turned off. I just had to move the cursor from screen to screen and
click on windows instead of having auto-raise bring them to the top.

Peter seemed to think this is a scaling issue.

Again, once the mouse stops responding, the problem can be corrected
by using <alt-tab> to select a window, then <alt-f7> to move the window
to screen0 (and only screen0). Once the mouse cursor is moved back to
screen0 via the keyboard arrow keys, the mouse starts working again.

Edward: This does seem like a different issue from the original problem
so maybe you should create a clone bug record.

[Robert (robert-redhat-bugs-1)]

I just recreated the problem again between screen0 and screen1.
All I did was drag my mouse cursor slowly from screen0 to screen1.
When it got to screen1, the cursor still moved, but all other
functionality (auto-raise and button clicks) stopped working.

[josef (josef-redhat-bugs-1)]

exactly what happens with my system. and the "fix" works, too.

(In reply to comment #29)

> Again, once the mouse stops responding, the problem can be corrected
> by using <alt-tab> to select a window, then <alt-f7> to move the window
> to screen0 (and only screen0). Once the mouse cursor is moved back to
> screen0 via the keyboard arrow keys, the mouse starts working again.
>
> Edward: This does seem like a different issue from the original problem
> so maybe you should create a clone bug record.

[Peter (peter-redhat-bugs)]

We had another debugging session and it looks like the cursor rendering for animated cursors is at fault. If you step through it in gdb, the cursors actually jump back to the old screen for a fraction of a second. This confuses the internal screen variables and triggers the bug.

Can you try to recreate the bug by switching the cursor theme to something without animated cursors?

[Robert (robert-redhat-bugs-1)]

I spent some time looking around for a non-animated cursor theme.
I didn't have much luck. It's difficult to even tell which themes
are animated and which are not. Also, I'm using gnome and it seems
as if most of the features for doing this seem to be kde-related.

Over the course of last week, I pulled both of my slow PCI nvidia
geforce fx5200 video cards out of the system and added a faster
9600GT pci-express card. (So now I'm down to two displays rather
than three). So far I haven't seen the problem with the faster
card. If necessary, I can go back to the older config for debugging
purposes. If not necessary, I'd rather keep my current configuration.
The problem is easy to recreate, given the other configuration, so
perhaps you can recreate the problem there with slower hardware.

I'll post again if the problem occurs with the fast video card.

[Robert (robert-redhat-bugs-1)]

I did manage to recreate the failure once on my faster video card
yesterday, but it's not easy to do.

[Peter (peter-redhat-bugs)]

Finally tracked it down. Caused by a WarpPointer request that would reset the root window of the sprite. In Xinerama, there's only one protocol root window (but more in the server), so suddenly the sprite ends up on a root window that doesn't have any actual windows.

Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1092389
RPMS available from: http://koji.fedoraproject.org/scratch/whot/task_1092389/

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.3-10.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1308

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.3-11.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1390

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.3-13.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

[Chris (chris-redhat-bugs)]

I'm hoping this also fixes bug 460793 as well, which has been bugging me since I upgraded to Fedora 9 over 6 months ago,

[Maxim (maxim-redhat-bugs)]

(In reply to comment #38)
> xorg-x11-server-1.5.3-13.fc10 has been pushed to the Fedora 10 stable
> repository. If problems still persist, please make note of it in this bug
> report.

I've been experiencing the same problem. The problem still persists with xorg-x11-server-Xorg-1.5.3-13.fc10.x86_64.

Can provide more info if necessary.

[Peter (peter-redhat-bugs)]

Maxim:
open a window, press alt+f7 to move it (if you're running metacity), then move the window with the cursor keys to the second screen. press enter to release the pointer - does the pointer work now? (same way to restore it, btw, just move the window back)

If not, this is the same problem (although I thought it'd been fixed). If it works, then what you are seeing is a different problem, please open a new bugreport for that.

[Stephen (stephen-redhat-bugs)]

I had been seeing this occur once every 2 or 3 days since updating to F10, but am now at 10 days without issue using xorg-x11-server-Xorg-1.5.3-13.fc10.i386. I'm using Xinerama over two DVI displays on a single card. Looks good so far, I'll followup here if I see it occur again.

[Maxim (maxim-redhat-bugs)]

(In reply to comment #41)
> Maxim:
> open a window, press alt+f7 to move it (if you're running metacity), then move
> the window with the cursor keys to the second screen. press enter to release
> the pointer - does the pointer work now? (same way to restore it, btw, just
> move the window back)

This test works as expected.

> If not, this is the same problem (although I thought it'd been fixed). If it
> works, then what you are seeing is a different problem, please open a new
> bugreport for that.

Okay.

[josef (josef-redhat-bugs-1)]

seems to be fixed, as i no longer have that problem. thanks.

[Chris (chris-redhat-bugs)]

As per my comment #39, this is now fixed for my setup - Hooray :-)

[Thomas (thomas-redhat-bugs)]

The problem also affects Fedora 9 badly. We've been running Peter's patch for over a month now on five dual head workstations without trouble.

Would be nice if the patch would also be pushed out to other Fedora 9 users
as this really hurts productivity. Thanks!

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.2-6.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-6.fc9

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.2-6.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.