Created attachment 325155 [details] xorg.conf With a Dell Latitude D820, recently upgraded from Fedora 8 to Fedora 10, the mouse sometimes becomes totally unresponsive to all input. I saw this under Fedora 8, but FAR more rarely. Usually when I have this problem, I have the problem immediately after starting X, but sometimes the mouse -- for no obvious reason -- becomes non-responsive. In all cases, the keyboard continues to work. Sometimes if I switch from X to a text console and back, the mouse will start working again. So far always, if I use keyboard shurtcuts to log out and then log back in, the mouse will start working again. How reproducible: Since upgrading to Fedora 10, I see this daily. I don't know how to cause this to occur and so far looking in logs I have not seen any obvious complaint correlated with this. I did see this message at my previous login (where I had this prolblem) GSynaptics couldn't initialize. You have to set 'SHMConfig' 'true' in xorg.conf or XFree86.conf to use GSynaptics but when I look at the xorg.conf (attached), it already has this line. I logged out and logged back in, and the second login (without this problem) does not have this complaint in .xsession-errors. There is no obvious problem in dmesg output or int messages.log.
a) we would need /var/log/Xorg.0.log from your computer as well, b) SHMConfig has been switched off in Fedora since at least early Fedora 9 (it is a security disaster in making) Thank you
Created attachment 325310 [details] My Xorg.0.log I'm having the same problem. I tried xev, and it showed no events when I click any mouse buttons and such. Keyboard continues to work. I'm seeing the problem 4 times a day. I will attach my xorg.conf file and .xsesson-errors as well.
Created attachment 325311 [details] My .xsession-errors This is my .xsession-errors file at the time of failure
Created attachment 325312 [details] My xorg.conf file Here is my xorg.conf file.
I'm willing to take test code and/or patches to debug this. I'm a Red Hat file system/kernel level developer and I'm willing to do whatever it takes to solve the problem.
FYI, you can remove all mouse/keyboard input sections from the xorg.conf, they're not doing anything anymore anyway. Edward: regarding the synaptics issue - remove the line Option "Device" "/dev/input/mice" (and the one with Procool auto-dev, it's default anyway). Also, when you say the "mouse" becomes unresponsive are you talking about a physical mouse you have connected as well (i.e. touchpad still works) or about the pointer on the screen? Edward and Robert: Please get evtest from http://people.freedesktop.org/~whot/evtest.c, compile it with gcc -o evtest evtest.c and run it against the device's event file (see /proc/bus/input/devices). Does it still show events there when the pointer is dead?
Hmm, OK, I compiled evtest and /proc/bus/input/devices gives me 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 evtest doesn't do anything but complain with files I tried under /sys/devices/platform/i8042/serio1/input/input6/, but if I try with /dev/input/event5 or event6 it appears to mostly work. So I run evtest when things are working OK and I get: $ ./evtest /dev/input/event6 Input driver version is 1.0.0 Input device ID: bus 0x11 vendor 0x2 product 0x8 version 0x6337 Input device name: "AlpsPS/2 ALPS GlidePoint" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 325 (ToolFinger) Event code 330 (Touch) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event type 3 (Absolute) Event code 0 (X) Value 537 Min 0 Max 1023 Event code 1 (Y) Value 453 Min 0 Max 767 Event code 24 (Pressure) Value 0 Min 0 Max 127 Grab failed: Device or resource busy Testing ... (interrupt to exit) but I get no events. I'm guessing I get no events because of the "Grab failed" complaint. So far, I've not tried a PS/2 mouse (or an external USB mouse) on this laptop. Thus, if I run evtest on the other mouse device, not surprisingly, the grab succeeds but I get no events. Next time things freeze up, I'll try plugging in a USB mouse and I'll run the above again and see if anything is different. What happens to me when things freeze up is that the touchpad *and* the button mouse *and* both sets of mouse buttons (above and below the touchpad) all become non-responsive.
synaptics puts a grab on the device, so the "grab failed" message will happen for any device using synaptics. For normal mice it should succeed though. There's another thing that you could try: add Option AutoAddDevices "off" to the ServerLayout This will force the mouse driver to load. If you can reproduce the problems with the mouse driver as well, that means it's either the X server, or the kernel. If not, then it's the driver. However, since Robert doesn't have a touchpad but sees the same issues, it doubt it's the driver.
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.
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.
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.
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.
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?
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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).
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.
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.
Created attachment 327058 [details] dmesg from bootup where the mouse was non-responsive
Created attachment 327059 [details] dmesg from bootup where the mouse was responsive and normal
*** Bug 475945 has been marked as a duplicate of this bug. ***
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.
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.
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.
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?
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.
I did manage to recreate the failure once on my faster video card yesterday, but it's not easy to do.
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/
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
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
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'm hoping this also fixes bug 460793 as well, which has been bugging me since I upgraded to Fedora 9 over 6 months ago,
(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.
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.
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.
(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.
seems to be fixed, as i no longer have that problem. thanks.
As per my comment #39, this is now fixed for my setup - Hooray :-)
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!
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
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.