Description of problem: The mouse will move, but the OS does not register any clicks. Version-Release number of selected component (if applicable): kernel-2.6.27.21-170.2.56.fc10.x86_64 xorg-x11-server-common-1.5.3-15.fc10.x86_64 xorg-x11-server-utils-7.4-3.fc10.x86_64 xorg-x11-server-Xorg-1.5.3-15.fc10.x86_64 How reproducible: Random. Annoying, but I can't find a way to repeat this problem. Steps to Reproduce: 1. 2. 3. Actual results: Mouse does not click. ALT+CTL+TAB a couple of times fixes issue. Expected results: Mouse click is accepted by OS :) Additional info: This problem has occured on both work (T500) and home (Dell Inspiron 1525) machines. Today mdoyle reported the same problem on his X200.
as discussed over IRC, let's leave this bug open until we find how to reproduce the issue. It sounds much like a stuck grab, but that should be traceable to a particular application. Leaving the needinfo flag so we get reminded.
next time this happens, please run http://people.freedesktop.org/~whot/grabtest.c. (Compile with gcc -lX11 -o grabtest grabtest.c). Does it report success or failure?
compiled... and now we wait ;)
(In reply to comment #3) > compiled... > > and now we wait ;) Call me stupid, but I don't understand how this answer to question in comment 2. Could you elaborate on this a little bit, please?
Sorry Matej, I meant... 1. I've compiled Whot's code 2. I'm waiting for next time the mouse goes !click to run the code.
Passing the bug to Peter, and go guys with it wherever your hearts lead you!
Peter, It happened just now as I was reading the email from Matej ;) Application running: thunderbird-2.0.0.21-1.fc10.x86_64 Action performed: Selected an email... clicking "delete" Kernel: 2.6.27.21-170.2.56.fc10.x86_64 xorg: xorg-x11-server-Xorg-1.5.3-15.fc10.x86_64 Config wise.... I've got sloppy focus windows going on gnome. ------------------------------------------ Results of grabtest: (and it's happened as I tried to navigate to the xterm !!) [anross@mithrandir bin]$ ./grabtest Grabbing pointer ... success. Grabbing keyboard ... success. (had to get this via ssh....) -------------------------------------------
And again.... switching from one tab in FF to another.... firefox-3.0.8-1.fc10.x86_64 grabtest .. success :D im going for a reboot... see if that helps ;)
I have exactly the same problem on my MacBook (4,1) running Fedora 10 x86_64. It seems to happen randomly, but has been happening more often lately. Maybe once every 5-10 minutes. Ctrl+Alt+Arrow keys will usually resolve it temporarily, but sometimes it doesn't, and my only option is to log out. This happens in Gnome and Openbox, but I haven't noticed it in DWM (light tiling WM). I'm not at the machine in question now, so I can't run the grabtest program now. I will do that later. I have, however, tried to run xprop while I was having this issue, and xprop complained that it couldn't grab the pointer.
(In reply to comment #9) > I have exactly the same problem on my MacBook (4,1) running Fedora 10 x86_64. > > It seems to happen randomly, but has been happening more often lately. Maybe > once every 5-10 minutes. Ctrl+Alt+Arrow keys will usually resolve it > temporarily, but sometimes it doesn't, and my only option is to log out. I take it ctrl+alt+arrow switch workspaces? switching workspaces is akin to unmapping all windows - and as soon as a window becomes not viewable, the grab for that window is released. so those cases where it just works - I'd say they are indeed stuck grabs. if it doesn't, it's either a grab by something that's not unmapped (the panel maybe) or it's something else.
I'm suffering from this as well. I've found http://thread.gmane.org/gmane.linux.redhat.fedora.general/332310/focus, which looks relevant. For me, this happens perhaps once a day or so. I'm using Fedora 9 with all updates. My typical applications are Seamonkey, VMware, vncviewer, gnome-terminal. I've determined that only one of these applications are enough to trigger the problem. What happens seems to be an unintential grab: All events goes to one application. One time, the this application was the trashcan applet. Typically, it is gnome-terminal or Seamonkey (this is the applications I'm using most).
Christian's shortcut to switch workspaces also helped me. Twice more.... 1. Fininshed typing email, went to click submit 2. Typed a comment in IRC, went to change channels Apps running: xchat-2.8.6-3.fc10.x86_64 thunderbird-2.0.0.21-1.fc10.x86_64 firefox-3.0.10-1.fc10.x86_64 Generally, once this problems occurs it keeps on happening and the best fix is a reboot :(
i would add one more voice to this bug. happening for the last 6 days. randomly. sometimes i can get way with alt+tab but most of the time have to kill my xorg completely. FC10, x86_64, Thinkpad T61p
*** Bug 494233 has been marked as a duplicate of this bug. ***
FWIW, i checked the commit history for the server around the time this bug and Bug #494233 popped up and it doesn't change anything that could trigger this bug.
Here's a method that hopefully lets us find out more. It requires that you have a second machine and that the xorg-x11-server-debuginfo package is installed. 1. ssh into the machine when the bug has been triggered (i.e. the mouse stopped responding) 2. attach gdb by running "sudo /usr/lib/debug/usr/bin/Xorg.debug `pidof Xorg`". 3. print the ID of the grab's resource. in gdb, run p/x inputInfo.pointer->deviceGrab.grab->resource (rawhide) p/x inputInfo.pointer->grab->resource (F10) This should print some number, e.g 0x200000. This is the client ID. 4. detach gdb by running "detach", then ctrl+d to exit gdb 5. run "xwininfo -root -children" and compare the output. There's likely a set of windows that are in the client's ID range (e.g. 0x200001 is the first window of client 0x200000). Try to find some identifier that may tell us what client this is. Note you may have to set the DISPLAY environment variable to run xwininfo, e.g. export DISPLAY=:0 if you server is running on display 0. Repeat these steps each time the problem occurs. If it is the same application each time, this means we can start narrowing down scenarios to trigger it.
Updated instructions if Comment #16 does not reveal a suitable client ID (which can happen if a passive grab gets stuck, not an active one). 6. p/x clientTable 7. In this table, one client will have a endFakeID below the grab's resource ID and the next client a endFakeID above the grab's resource ID. This means the second client is our man. 8. print this client's expectID in the clientTable entry. Match this ID with the output from xwininfo as listed in Comment #16, step 5. Kill this client. If the pointer goes back to normal, you have identified the right one. Andrew's machine just locked up and the culprit was a stuck grab in metacity.
I've installed the debug package but I can't seem to run the Xorg.debug command, ls -l Xorg.debug -rwxrwxrwx 1 root root 7259672 2009-03-10 18:22 Xorg.debug /usr/lib/debug/usr/bin> ./Xorg.debug `pidof Xorg` ./Xorg.debug: Command not found. /usr/lib/debug/usr/bin> Is there something else I need to install?
I killed all of the applets which didn't have any effect. I then killed metacity and that fixed the problem. Here are the applets that were running Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ bjrosen 3532 0.1 1.5 286048 61600 ? S May23 3:11 imsettings-applet --disable bjrosen 3533 0.0 0.0 213488 2732 ? S May23 0:00 kerneloops-applet bjrosen 3543 0.0 0.2 309908 10516 ? S May23 0:04 nm-applet --sm-disable bjrosen 3544 0.0 0.1 245580 5180 ? S May23 0:00 bluetooth-applet bjrosen 3658 0.0 0.2 319368 9256 ? S May23 0:18 /usr/libexec/wnck-applet -- bjrosen 3671 0.0 0.1 317504 5548 ? S May23 0:00 /usr/libexec/trashapplet -- bjrosen 3680 0.0 0.1 338768 6416 ? S May23 1:11 /usr/libexec/sensors-applet bjrosen 3684 0.0 0.1 299676 5024 ? S May23 0:24 /usr/libexec/cpufreq-applet bjrosen 3689 0.0 0.2 374760 9536 ? Sl May23 0:00 /usr/libexec/mixer_applet2 bjrosen 3693 0.0 0.4 494036 16868 ? Sl May23 0:04 /usr/libexec/clock-applet -
(In reply to comment #18) > I've installed the debug package but I can't seem to run the Xorg.debug > command, the Xorg.debug binary is the one you have to load into gdb. You don't run it directly. Sorry, I just realised I had a typo regarding this in Comment #16. $> sudo gdb /usr/lib/debug/usr/bin/Xorg.debug `pidof Xorg`
Matthias - any ideas what in metacity could trigger that?
It just happened again. Killing metacity fixed the problem so it's starting to be pretty conclusive that the issue is with metacity.
Joshua, i am not using metacity, i have compiz all the time, and yet this does happen to my machine randomly too, sometimes 10 times a day, other days none.... i will try to get this debugging when i have a chance. kiryl ps. so my point is - it may not be metacity :)
I just upgraded to Fedora 11. I've never seen this bug before, but now I'm seeing exactly this behavior every single time I left-click in any window or the desktop. The keyboard continues to respond fine, and the mouse will move but won't click; it also won't raise other windows automatically nor will it change shape. Destroying the window with a keyboard shortcut releases the mouse. If there's a context window pop-up somewhere in the window, then right-clicking to bring it up and then dismissing the context window releases the stuck grab. Various window manipulating CTRL-ALT-TAB, CTRL-ALT-arrow key I downloaded and compiled grabtest. Naturally, I had to get the mouse window stuck inside the terminal, but that's no problem; all I have to do is click anywhere inside the gnome-terminal window or in its toolbar. After doing so, I ran grabtest and: ./grabtest Grabbing pointer ... FAILED (1) Grabbing keyboard ... success. I just upgraded to Fedora 11. I actually didn't see this behavior when first upgrading (from DVD), but after rebooting last night I saw it. It's possible that some update did it to me.
I should note that I have updates-testing enabled, so it could be from a testing package.
John, do you have anything installed related to vmware? or vmware firefox plugin ? Kiryl
No. Disabling -testing and downgrading to xorg-x11-server-1.6.1.901-1.fc11 just now completely solved the problem for me. I don't think that package should be pushed to stable. My problem is thus probably somewhat different from the original bug.
I actually have to note something else: when xorg-x11-server-1.6.1.901-2 is installed, the problem with not releasing grabs always shows up. It also shows up after upgrading to the new version within an X session, without logging out to restart X, and also remains if I log out of X. when on xorg-x11-server-1.6.1.901-1, I still see the same problem the FIRST login session after rebooting (I am using the graphical boot), but it then goes away completely after logging out of X and logging back in.
I am having the EXACT same problem that John Thacker spoke about. From his post: "I just upgraded to Fedora 11. I've never seen this bug before, but now I'm seeing exactly this behavior every single time I left-click in any window or the desktop. The keyboard continues to respond fine, and the mouse will move but won't click; it also won't raise other windows automatically nor will it change shape. Destroying the window with a keyboard shortcut releases the mouse." It's also the same with the different versions of xorg that he mentions. Mine is fine once I log out and then log back in. sigh I can't believe this is still around after his post nearly 2 months ago. It is one big pain. :(
The recent update for xorg-x11-server (-common, -devel, -Xorg) to version 1.6.2-3 has made this problem *much* worse for me. Previously it occurred only the first time I logged into X after rebooting; now it spontaneously happens all the time. It fixes temporarily after logging out and logging back in, but then happens again later. Anything else I can do to help? This is making X completely unusable.
Once again I'm going to downgrade back to 1.6.1.901-1, which still has the problem, but at least it only occurs the first time I log in.
John, I have been googling like crazy (I think my IP is all over Google like a rash) and came across this thread and post #31 detailed turning off the cpuspeed service and that seemed to do the trick. http://forums.fedoraforum.org/showthread.php?t=188757&page=3 Since doing that 20 minutes ago my computer has worked fine and I could get it to lock up 100% of the time on 100% of the things I'd try. So far it's working as normal. I normally turn cpuspeed off anyway since 'm a highly OCed system, I just hadn't done it yet.
Just a note...the same thing happened to me so disabling cpuspeed didn't fix it. I messed and messed with it and finally decided to switch the mouse. When I went to do that I noticed that the mouse cord didn't reach to the tower so I had used a USB extension cord that came with one of my flash drives. I took that off and plugged the mouse into the hub on my 24" Dell flatscreen and my mouse has been working fine ever since. I do seem to recall that the USB extension cable gave me problems before (on a different computer) but figured it was just a fluke. It worked fine on FC10. Maybe something changed in the software and the extension just didn't get along with it. who knows. I'll update if the problem comes back.
Re #33 I have had this problem on 3 separate machines - all with different types of mouse - wired usb mouse - cordless usb mouse - trackball / touchpad on laptop. Though it hasn't yet happened on F11. :-/
For an update to this, I replaced my wireless keyboard (but not my wireless mouse) with a USB keyboard and all became well instantly. So I think that many of these are some sort of tricky hardware bugs.
Today, I can reproduce this problem on F11 in any application by simply pressing both mouse buttons at the same time. 100% repeatable. I can get rid of the "freeze" by pressing "like a maniac" on the mouse buttons and keyboard (using the workspace switching hotkeys Ctrl-Alf-Left/Right). It's frustrating to see that this "disease" has spread from my laptop to my workstation.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just started having this problem with Fedora 12 on a Thinkpad T500. It happens consistently every day shortly after I boot and log in. For me, switching workspaces (with Ctl-Alt-{Left,Right}Arrow) sometimes fixes it temporarily. Killing gnome-panel sometimes fixes it temporarily. Killing and restarting metacity sometimes fixes it temporarily. The only "permanent" way I've been able to keep it from happening again is to kill gdm-binary and log back in. I'm going to go ahead and change the 'version' to F12 since its reproducible in that version. Next time it happens, I'll try some of the diagnostic steps described in Comment #2 and Comment #16 ff.
Created attachment 375850 [details] Output of "xwroot -root -children" Predictably, this happened again to me today. Here's the information requested in Comment #16 ff (the file mentioned in Comment #2 seems to have disappeared -- I got a 404 when I tried to follow the link): (gdb) p/xinputInfo.pointer->deviceGrab.grab->resource $1 = 0x2200000 The output of "xwinfo -root -children" is attached.
Created attachment 375851 [details] Output of "xwinfo -root -children" after "killall firefox" After running "killall firefox" the problem persisted. I re-ran gdb and xwinfo and here are the results. (gdb) p/x inputInfo.pointer->deviceGrab.grab->resource $1 = 0x2e00000 Output of "xwinfo -root -children" is attached
I ran "killall wnck-applet" (and then told gnome-panel not to restart them) and with both that and Firefox stopped (I'm using Epiphany for the moment) the behavior is much more chaotic now. The ability of the mouse to click on things comes and goes. Right now, I can click on things in the focused window, but can't switch to other windows using the mouse (I use mouse focus, if that makes a difference). Also, switching workspaces (with Ctl-Alt-<arrow>) will fix it temporarily. Although it just occurred again, and now: (gdb) p/x inputInfo.pointer->deviceGrab.grab->resource $3 = 0x4400000 $ xwininfo -root -children | grep 0x44 0x4405cb8 "Web Browser": ("epiphany" "Epiphany") 117x94+1950+930 +1950+930 0x4400c65 "Web Browser": ("epiphany" "Epiphany") 1246x180+1682+137 +1682+137 0x4400bcc "Web Browser": () 10x10+-100+-100 +-100+-100 0x4400823 "Web Browser": ("epiphany" "Epiphany") 200x200+0+0 +0+0 0x4400001 "Web Browser": ("epiphany" "Epiphany") 10x10+10+10 +10+10 Maybe it just happens to be whatever app is in the foreground when the problem occurs. I don't know. I don't know if this makes a difference either, but I started Epiphany in a gnome terminal. Epiphany currently has the focus and I can't switch focus to another window without using Alt-Tab. Whenever I click on another window, Epiphany emits the following in the gnome-terminal window in which I started Epiphany: (epiphany:8997): Gdk-CRITICAL **: gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed (epiphany:8997): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (epiphany:8997): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed I'm more than happy to continue helping to diagnose this -- it's driving me nuts so I'll do whetever I can to help get it resolved quickly. Thanks.
Any ideas? Any other information you'd like me to collect? This is becoming a real pain in the derriere for me as it's now happening multiple times a day.
I have two computers that seem to suffer from this bug. However, the mouse stopped freezing after I uninstalled both synergy and the proprietary nvidia drivers. As far as I can tell the problem remains if I have either installed (well, at least if they are running). I got rid of those over a week ago and haven't had a mouse freeze yet. Also, both those machines are 64-bit machines. I have the nvidia drivers installed on my 32-bit laptop and haven't noticed a problem.
I have seen this exact same bug but only on systems with nvidia cards. The system used to have the proprietary nvidia drivers installed but they were unstalled (may be something got messed up in that process).
I'm seeing this on a Lenovo T500, which does _not_ have an nVidia graphics card, so this problem is not limited to systems with only nVidia hardware. $ lspci | grep -i graph 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
All well until fedora 10; passing to fedora 11 and now in fedora 12 the mouse move, but I have great problems to click (a trick to click is to go in another workspace (Alt 2, or 3, etc.) and click on principal menu. Returning to original workspace, i can click, but after a few the problem returns. I have seen that the problem with mouse starts in the boot time: from dmesg: usb 1-1.1: New USB device found, idVendor=04fc, idProduct=0538 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Trust Mouse 15178 usb 1-1.1: Manufacturer: MLK usb 1-1.1: configuration #1 chosen from 1 choice input: MLK Trust Mouse 15178 as /devices/pci0000:00/0000:00:10.4/usb1/1-1/1-1.1/1-1.1:1.0/input/input5 generic-usb 0003:04FC:0538.0001: input,hiddev96,hidraw0: USB HID v1.10 Mouse [MLK Trust Mouse 15178] on usb-0000:00:10.4-1.1/input0 drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 ... drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 usb 1-1.1: USB disconnect, address 3 usb 1-1.1: new low speed USB device using ehci_hcd and address 10 usb 1-1.1: New USB device found, idVendor=04fc, idProduct=0538 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Trust Mouse 15178 usb 1-1.1: Manufacturer: MLK usb 1-1.1: configuration #1 chosen from 1 choice input: MLK Trust Mouse 15178 as /devices/pci0000:00/0000:00:10.4/usb1/1-1/1-1.1/1-1.1:1.0/input/input6 generic-usb 0003:04FC:0538.0002: input,hiddev96,hidraw0: USB HID v1.10 Mouse [MLK Trust Mouse 15178] on usb-0000:00:10.4-1.1/input0 drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 ... drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 usb 1-1.1: USB disconnect, address 10 usb 1-1.1: new low speed USB device using ehci_hcd and address 11 usb 1-1.1: New USB device found, idVendor=04fc, idProduct=0538 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Trust Mouse 15315 usb 1-1.1: Manufacturer: MLK usb 1-1.1: configuration #1 chosen from 1 choice input: MLK Trust Mouse 15315 as /devices/pci0000:00/0000:00:10.4/usb1/1-1/1-1.1/1-1.1:1.0/input/input7 generic-usb 0003:04FC:0538.0003: input,hiddev96,hidraw0: USB HID v1.10 Mouse [MLK Trust Mouse 15315] on usb-0000:00:10.4-1.1/input0 drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 drivers/hid/usbhid/hid-core.c: can't reset device, 0000:00:10.4-1.1/input0, status -71 usb 1-1.1: USB disconnect, address 11 usb 1-1.1: new low speed USB device using ehci_hcd and address 12 usb 1-1.1: device not accepting address 12, error -32 usb 1-1.1: new low speed USB device using ehci_hcd and address 13 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: new low speed USB device using ehci_hcd and address 14 usb 1-1.1: device not accepting address 14, error -32 usb 1-1.1: new low speed USB device using ehci_hcd and address 15 usb 1-1.1: device not accepting address 15, error -32 hub 1-1:1.0: unable to enumerate USB device on port 1 usb 1-1.1: new low speed USB device using ehci_hcd and address 16 usb 1-1.1: New USB device found, idVendor=04fc, idProduct=0538 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Trust Mouse 15178 usb 1-1.1: Manufacturer: MLK usb 1-1.1: configuration #1 chosen from 1 choice input: MLK Trust Mouse 15178 as /devices/pci0000:00/0000:00:10.4/usb1/1-1/1-1.1/1-1.1:1.0/input/input8 generic-usb 0003:04FC:0538.0004: input,hiddev96,hidraw0: USB HID v1.10 Mouse [MLK Trust Mouse 15178] on usb-0000:00:10.4-1.1/input0 Can this is the core of the problem?
Yesterday i made an update via yum: the application updated are: Jan 24 20:12:14 Updated: mono-core-2.4.3.1-1.fc12.x86_64 Jan 24 20:12:23 Updated: kdepimlibs-4.3.4-2.fc12.x86_64 Jan 24 20:12:24 Updated: 1:gnome-utils-libs-2.28.3-1.fc12.x86_64 Jan 24 20:12:24 Updated: kdepimlibs-akonadi-4.3.4-2.fc12.x86_64 Jan 24 20:12:25 Updated: ksysguardd-4.3.4-6.fc12.x86_64 Jan 24 20:12:33 Updated: 1:tcl-8.5.7-5.fc12.x86_64 Jan 24 20:12:34 Updated: amarok-utils-2.2.2-3.fc12.x86_64 Jan 24 20:13:13 Updated: 1:gnome-utils-2.28.3-1.fc12.x86_64 Jan 24 20:13:14 Updated: 2:ntfs-3g-2010.1.16-1.fc12.x86_64 Jan 24 20:13:16 Updated: gdb-7.0.1-29.fc12.x86_64 Jan 24 20:13:17 Updated: id3v2-0.1.11-10.fc12.x86_64 Jan 24 20:13:19 Updated: mono-data-2.4.3.1-1.fc12.x86_64 Jan 24 20:13:20 Updated: mono-data-sqlite-2.4.3.1-1.fc12.x86_64 Jan 24 20:13:20 Updated: 1:java_cup-0.11a-1.fc12.noarch Jan 24 20:13:38 Updated: thunderbird-3.0.1-1.fc12.x86_64 Jan 24 20:13:40 Updated: kdepimlibs-4.3.4-2.fc12.i686 Jan 24 20:13:41 Updated: kdepimlibs-akonadi-4.3.4-2.fc12.i686 Jan 24 20:13:42 Updated: 2:ntfs-3g-2010.1.16-1.fc12.i686 Jan 24 20:13:45 Updated: kdebase-workspace-libs-4.3.4-6.fc12.x86_64 Jan 24 20:13:58 Installed: kdebase-workspace-4.3.4-6.fc12.x86_64 Jan 24 20:13:59 Updated: amarok-libs-2.2.2-3.fc12.x86_64 Jan 24 20:14:07 Updated: gnome-media-libs-2.28.5-1.fc12.x86_64 Jan 24 20:14:09 Updated: mono-web-2.4.3.1-1.fc12.x86_64 Jan 24 20:14:10 Updated: mono-winforms-2.4.3.1-1.fc12.x86_64 Jan 24 20:14:14 Updated: gnome-media-2.28.5-1.fc12.x86_64 Jan 24 20:14:22 Updated: amarok-2.2.2-3.fc12.x86_64 Jan 24 20:14:24 Updated: kdm-4.3.4-6.fc12.x86_64 Jan 24 20:14:26 Updated: kdebase-workspace-libs-4.3.4-6.fc12.i686 Jan 24 20:14:27 Updated: mono-extras-2.4.3.1-1.fc12.x86_64 Jan 24 20:14:30 Updated: monodoc-2.4.3.1-1.fc12.x86_64 now dmesg is: usb 1-1.1: new low speed USB device using ehci_hcd and address 3 usb 1-1.1: New USB device found, idVendor=04fc, idProduct=0538 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Trust Mouse 15178 usb 1-1.1: Manufacturer: MLK usb 1-1.1: configuration #1 chosen from 1 choice input: MLK Trust Mouse 15178 as /devices/pci0000:00/0000:00:10.4/usb1/1-1/1-1.1/ 1-1.1:1.0/input/input5 generic-usb 0003:04FC:0538.0001: input,hiddev96,hidraw0: USB HID v1.10 Mouse [ML K Trust Mouse 15178] on usb-0000:00:10.4-1.1/input0 And now all seems resolved!
In my case the problem persisted even in up to date Fedora 12 (as of Jan-26-2010). I was able to get rid of this problem by changing the keyboard. My previous keyboard was also a USB keyboard but it had a USB <-> PS/2 adapter and the keyboard was PS/2 itself. So this bug may have something to do with certain exotic keyboard models? (I did not change the mouse or anything related to it)
Guys, I started having the exact same problem this morning on Fedora 12 (system fully up-to-date). I rebooted, it didn't help -- within the first 2min the problem reappeared, very badly: I could switch apps using Alt-TAB, but not by clicking. The keyboard input worked OK, and I could click on the window that had focus *at the beginning*. After a while, I couldn't do even that! Another important clue: after reboot I managed to open Epyphany and look at this bug. However, after looking at it for a while, things degraded quickly - I could not click even in the window with the focus - in Epyphany, I tried to bookmark the bug, but pressing Alt-B to get to the menu didn't quite work. What happened was that the "Bookmark" menu-item highlighted, but there was no menu underneath the "Bookmark" word. Same for any other menu. At that point all I could do is reboot. Managed to open Epyphany again to write this, and the bug showed up in full force. I can not use my box AT ALL! Someone please change the Severity and Priority to the highest possible level, as it renders the machine useless. Notes: - I've never expericenced this bug before, I blame the last set of updates maybe? - I have installed the debug package as in Comment #16, but I can't find Xorg.debug, what gives? Right now I hope to be able to submit this report, and I'll have to reboot again, but how can I re-gain control of my computer? This is my main work box, I can not function without it!
Aha, after killing Epiphany I regained control of the mouse. I've restarted it to submit this report, and it happened again. Arrhhhh! At least it seems this time I can still click inside it.
So, sequence of events was: - open Epiphany (the only app) --> bug - close Epiphany --> regain control - open Terminal, then Epiphany --> bug - close Epiphany --> bug remains - close Terminal --> bug remains - switch VC, kill metacity --> bug remains - switch VC, kill all applets --> bug remains - switch VC, kill gdm-binary --> regain control Now I'm running XFCE, lets see if I can still trigger it.
No, it works properly in XFCE. Folks, this is a _major_ problem -- any info/interest/anything?
Well, I have plenty of interest in getting it fixed, but I don't really know how I can help. I've already used all my votes on this bug. I use Gnome, maybe I'll switch to KDE for awhile and see if it happens there. Also, it only seems to happen to me with an open web browser (it happens in both chrome and firefox). Like I think I mentioned earlier getting rid of the nvidia drivers and synergy has made the problem occur much less frequently.
Well, for me: - it's not happening in XFCE, so I think it's GNOME related - I don't use synergy at all - I go have an nVidia card, but I'm not using the closed-source driver I still don't see how this can be a "medium" severity bug... It completely disables the machine, it might as well as not boot.
I've been using KDE for a few hours now without any trouble. So, it does seem to be Gnome related. However, I haven't been seeing the problem as often recently. Maybe I'll reinstall synergy and try to use it with KDE. I agree, this is very severe. Maybe if we can get more people to vote for this. It sure seems to affect a lot of people.
It has been now quite some time since I changed the keyboard and the problem has never showed up again. This was after switching from PS/2 keyboard to USB. Everything works great under gnome etc. So could it be that some keyboards are causing the issue but it is just gnome that somehow triggers this?
Hm, it might be coincidence, because I have a USB keyboard, not a PS/2 one, and _nothing_ changed in the hardware of my box when the problem appeared. However, switching from a completely non-working GNOME to XFCE solved it right away (despite the fact that I use the same apps as under GNOME more-or-less), so it is GNOME-related somehow...
It's been a year since I last saw this problem but it's come back in the last couple of days. Previously I saw it on my laptop which was running F10 at the time, now I'm seeing it on my desktop. Until last week I was running F9 with NVidia Binary drivers on my desktop and I never had a problem with that set up. I just switched to F12 with the Nouveau driver and I've had the mouse freeze twice in the last 24 hours. I think something is happening that hoses the graphics board. The symptom now is that the mouse will move and nothing happens. However when I sshed into the system and killed Firefox and Thunderbird they were still displayed. I then killed Xorg, it restarted X but when it came back I still had all of the windows that were up before and I had no mouse cursor at all. I tried killing it a second time with the same result. I had to do a complete reboot to clear the problem.
I've suffered from this problem more than a year now. My conclusion is that it is hardware related. I'm running F11 on many machines, but the freeze mostly happens on my laptop. As I mentioned in comment #36, I can get rid of the freeze by rapidly pressing all three mouse buttons. Then, this shows up in the kernel log: Mar 13 22:16:44 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5 Mar 13 22:16:44 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1 Mar 13 22:16:44 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched. I'm running XP on the same laptop, and in some cases, one button gets stuck down, but only for a short period of time. Perhaps the hardware is buggy, but XP handles it better.
Today, this bug caused a complete lockup of my laptop. First, the mouse buttons was messed up. When I tried the escape from this situation by rapidly pressing multiple buttons, which usually works, the mouse pointer stopped moving, and everything else has hung as well. I had to do a hard reboot. Not good, embarrassing that XP is more stable... Anyway, the last thing in the log was: Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 5 Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6 Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 3 Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 2 Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1 Mar 27 21:19:37 sabina kernel: psmouse.c: issuing reconnect request Mar 27 21:19:39 sabina kernel: input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input20 The last line puzzles me.
(In reply to comment #62) > Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at > isa0060/serio1/input0 lost sync at byte 5 > Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at > isa0060/serio1/input0 lost sync at byte 6 > Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at > isa0060/serio1/input0 lost sync at byte 3 > Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at > isa0060/serio1/input0 lost sync at byte 2 > Mar 27 21:19:37 sabina kernel: psmouse.c: DualPoint TouchPad at > isa0060/serio1/input0 lost sync at byte 1 > Mar 27 21:19:37 sabina kernel: psmouse.c: issuing reconnect request > Mar 27 21:19:39 sabina kernel: input: PS/2 Generic Mouse as > /devices/platform/i8042/serio1/input/input20 > > The last line puzzles me. touchpads have a touchpad mode and a generic PS2 mouse mode. to switch the touchpad into touchpad mode the kernel sends down a set of commands to the pad. If the kernel loses sync and doesn't re-init the pad it'll just show up as generic mouse. That's what the error here means.
For what it's worth, I also kept losing my left mouse button. It started some time during F12 (sorry for the lack of precision there). Happened several times a week. Sometimes a virtual desktop switch brought it back briefly. Switch to another user, mouse works. Switch back, left button's dead again. I tried killing metacity once or twice, didn't help. Logging out and back in fixed it. Emacs, gnome-terminal, firefox, not much else. I switched to XFCE, and the problem is gone.
Same behaviour here on Fedora 12. But: I use KDE 4.4.5, not Gnome. So it should not be related to Gnome.
(1) If you are experiencing this problem: * Does this happen when you are not tunnelling X ? * When it happens, attach an external mouse. I found that the external mouse wouldn't click either. (2) This may help with debugging: I had the unclickable mouse problem with F12 especially when I was tunnelling X with ssh -2XC and it seemed to happen very quickly when I was doing so to several machines at once. FWIW it so happens that one such machine was running an older version of RHEL 5. Usually I'd lose the left button, sometimes the right, sometimes both. I've upgraded to F13 and have (perhaps superstitiously, but I can't afford these mouse lockups) avoided tunnelling X; haven't experienced this problem since. Hope that helps track down the bug!
In my case there was no tunnelling of X, so that can't be it. Also, it happened to me on my desktop with always uses an external mouse...
Andrew, are you still experiencing this bug? It seems fixed on my systems.
(In reply to comment #69) > Andrew, are you still experiencing this bug? > It seems fixed on my systems. Hi Phil, No, haven't seen this issue since I updated to F12. Currently have F14 on that machine and no problems. Regards, Andrew
Great! I propose you or Peter can close this bug report. (I can't do it, I see status ASSIGNED rather than a pulldown status menu underneath this text entry box) Best, Phil
Closing per general agreement.
I'm still seeing this behavior on Fedora 14, 15 and now 16 but as this ticket is already closed (IIUC due to people agreeing that the problem can no longer be produced, though the CANTFIX resolution baffles me), I've opened a new ticket for my problem: Bug #741553. Just wanted to let the commenters here know about it in case someone is still interested in this problem.