Some time after login, the mouse suddenly stops working. Mouse clicks have no effect on most of the buttons I click at. The focus stays at the program, which was active at the crash. Every click is dedicated to that program (wherever I click). One of the few things I can do is to mark text (when there is text available at the program). Keyboard input is recognized properly. It seems random, I can't reproduce the bug at these specific events. (Somehow I can reproduce the bug only one time after it crashed. When I try to reproduce it the second time, nothing goes wrong.) After I restart Xorg, everything goes back to normal. Some other guys have this bug, too. It appears on Gnome and KDE with proprietary NVidia driver and with open source ati driver. Operating system: Arch Linux (fresh install) X.Org X Server 1.7.3.902 (1.7.4 RC 2) Release Date: 2009-12-26 Thank you very much. Greetings!
Hey, I also am experiencing this problem. The guys at ubuntu are running into it as well, and have filed a bug report on it. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/362359 It seems to be either related to xinerama in x.org, which is installed in x.org even if you don't use it, or a bug with synaptic.
Created attachment 32847 [details] /var/log/daemon.log gdm simple greeter fails Unable to read from file /etc/arch-release
Hey, so I finally managed to track down some error messages in the logs. I have attached the following: /var/log/daemon.log /var/log/Xorg.0.log /var/log/gdm/:0-greeter.log /var/log/gdm/:0.log.1 here is a brief summary of the errors: ============================================================= daemon.log ============================================================= Jan 27 10:15:35 valkyrie gdm-simple-greeter[6532]: GLib-GObject-CRITICAL: g_param_spec_flags: assertion `G_TYPE_IS_FLAGS (flags_type)' failed Jan 27 10:15:35 valkyrie gdm-simple-greeter[6532]: GLib-GObject-CRITICAL: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed Jan 27 10:15:35 valkyrie gdm-simple-greeter[6532]: WARNING: Unable to read from file /etc/arch-release ============================================================= Xorg.0.log ============================================================= (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) Jan 27 10:15:34 NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon (II) Jan 27 10:15:34 NVIDIA(0): may not be running or the "AcpidSocketPath" X (II) Jan 27 10:15:34 NVIDIA(0): configuration option may not be set correctly. When the (II) Jan 27 10:15:34 NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will (II) Jan 27 10:15:34 NVIDIA(0): try to use it to receive ACPI event notifications. For (II) Jan 27 10:15:34 NVIDIA(0): details, please see the "ConnectToAcpid" and (II) Jan 27 10:15:34 NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X (II) Jan 27 10:15:34 NVIDIA(0): Config Options in the README. ============================================================= :0-greeter.log ============================================================= (polkit-gnome-authentication-agent-1:6530): GLib-GObject-WARNING **: cannot register existing type `_PolkitError' (polkit-gnome-authentication-agent-1:6530): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed gdm-simple-greeter[6532]: GLib-GObject-CRITICAL: g_param_spec_flags: assertion `G_TYPE_IS_FLAGS (flags_type)' failed gdm-simple-greeter[6532]: GLib-GObject-CRITICAL: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed gdm-simple-greeter[6532]: WARNING: Unable to read from file /etc/arch-release Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1200022 (Login Wind) ============================================================= :0.log.1 ============================================================= [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x4b04e8] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x4a9874] 2: /usr/bin/Xorg (xf86PostButtonEventP+0xcf) [0x48751f] 3: /usr/bin/Xorg (xf86PostButtonEvent+0xb9) [0x487649] 4: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f44f0b11000+0x375d) [0x7f44f0b1475d] 5: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f44f0b11000+0x5998) [0x7f44f0b16998] 6: /usr/bin/Xorg (0x400000+0x72027) [0x472027] 7: /usr/bin/Xorg (0x400000+0x11de63) [0x51de63] 8: /lib/libpthread.so.0 (0x7f452541c000+0xee80) [0x7f452542ae80] 9: /lib/libpthread.so.0 (0x7f452541c000+0xffff80bada1e4177) [0xffffffffff600177]
Created attachment 32848 [details] /var/log/Xorg.0.log Open ACPI failed (/var/run/acpid.socket)
Created attachment 32849 [details] /var/log/gdm/:0-greeter.log Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1200022 (Login Wind)
Created attachment 32850 [details] /var/log/gdm/:0.log.1 Backtrace to Xorg: [mi] EQ overflowing. The server is probably stuck in an infinite loop. 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x4b04e8] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x4a9874] 2: /usr/bin/Xorg (xf86PostButtonEventP+0xcf) [0x48751f] 3: /usr/bin/Xorg (xf86PostButtonEvent+0xb9) [0x487649] 4: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f44f0b11000+0x375d) [0x7f44f0b1475d] 5: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f44f0b11000+0x5998) [0x7f44f0b16998] 6: /usr/bin/Xorg (0x400000+0x72027) [0x472027] 7: /usr/bin/Xorg (0x400000+0x11de63) [0x51de63] 8: /lib/libpthread.so.0 (0x7f452541c000+0xee80) [0x7f452542ae80] 9: /lib/libpthread.so.0 (0x7f452541c000+0xffff80bada1e4177) [0xffffffffff600177]
I tested, if older versions of xorg-server and evdev will fix the bug. I downgraded as far back as xorg-server-1.7.1-1 and xf86-input-evdev-2.3.0-1. This had no effect at all, the bug is still there.
the new xorg, xorg-server 1.7.4.901-1 did not correct this problem.
I have exactly the same problem. If there is any info I could provide, just ask and I'll try to provide it.
Out of four people I know who experience this bug three are using KDE's global mouse gestures or have even noticed a strong correlation between enabled mouse gesture system and the frequency of the bug occuring. It can't actually be a bug in that code for various reasons; still, it might give some hints about what is going wrong. There are a few things that get called very often in that code: - XGrabButton( QX11Info::display(), button, mods[ i ], QX11Info::appRootWindow(), False, ButtonPressMask | ButtonReleaseMask | mask[ button ], GrabModeAsync, GrabModeAsync, None, None ); This is in a loop over i. "mods" is an array with all possible combinations of XCapL, XNumL and XScrL. "button" is one specific button that can be configured by the user, it will be 2 or 3 in most cases - XUngrabButton( QX11Info::display(), button, AnyModifier, QX11Info::appRootWindow()); - XAllowEvents( QX11Info::display(), AsyncPointer, CurrentTime ); - XUngrabPointer( QX11Info::display(), CurrentTime ); - XTestFakeButtonEvent( QX11Info::display(), button_P, True, CurrentTime ); Also: Installing and uninstalling of event filters using KDE methods which use Qt methods in turn; it's a bit too much for me to look into right now. I guess some of those will occur all the time in other programs anyway, but I wanted to list them all to be sure.
Hello, same here with debian squeeze (testing), xorg xserver 1.7.7 and kde 4.4. I can not reproduce this bug by command, but it appears roughly every hour. Actually its very annoying, since i have to close all my work and restart the xserver. I noticed that its still possible to use the mouse sometimes, but only the right button. Besides that every time this bug appears, it is not possible to use xkill: # xkill Select the window whose client you wish to kill with button 1.... xkill: unable to grab cursor Until now this bug did not appear in gnome, only when using kde (mouse gestures enabled). Best Regards WANA
This bug is still alive! Mouse focus is acting as described above. If i can help with any Information, tell me. This bug is very anoying and prevents me from using my gentoo system at all. when i call kwin --repclace i can use the mouse for a few minutes and than it is gone again. It seems that the mouse events are recognised by another application than the focused one. The mouse events "fall through". I have tested the following versions: xorg-server 1.9.5 and 1.10.0.902 (pre 1.10.1) xf86-input-synaptics 1.4.0 (1.3.0 does not compile anymore) xf86-input-evdev 2.6.0 xf86-video-intel 2.14 kwin 4.6.2 I get exactly the same synaptic error message in kdm.log, but it does not apear everytime the mouse behaviour starts misbehaving. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x45f8a8] 1: /usr/bin/X (mieqEnqueue+0x1f3) [0x45a523] 2: /usr/bin/X (xf86PostButtonEventM+0xaa) [0x47ea7a] 3: /usr/bin/X (xf86PostButtonEvent+0xe5) [0x47ec35] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f2be1a49000+0x3f30) [0x7f2be1a4cf30] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f2be1a49000+0x619e) [0x7f2be1a4f19e] 6: /usr/bin/X (0x400000+0x6d547) [0x46d547] 7: /usr/bin/X (0x400000+0x11c459) [0x51c459] 8: /lib/libpthread.so.0 (0x7f2be4cdd000+0xf120) [0x7f2be4cec120] 9: /lib/libc.so.6 (writev+0x31) [0x7f2be3d10511] 10: /usr/bin/X (0x400000+0x69ccc) [0x469ccc] 11: /usr/bin/X (0x400000+0x619cd) [0x4619cd] 12: /usr/bin/X (FlushAllOutput+0x139) [0x462599] 13: /usr/bin/X (0x400000+0x30be6) [0x430be6] 14: /usr/bin/X (0x400000+0x24a0a) [0x424a0a] 15: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f2be3c64bbd] 16: /usr/bin/X (0x400000+0x245a9) [0x4245a9] FATAL: Module fbcon not found. The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x45f8a8] 1: /usr/bin/X (mieqEnqueue+0x1f3) [0x45a523] 2: /usr/bin/X (xf86PostButtonEventM+0xaa) [0x47ea7a] 3: /usr/bin/X (xf86PostButtonEvent+0xe5) [0x47ec35] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f84431eb000+0x3f30) [0x7f84431eef30] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f84431eb000+0x619e) [0x7f84431f119e] 6: /usr/bin/X (0x400000+0x6d547) [0x46d547] 7: /usr/bin/X (0x400000+0x11c459) [0x51c459] 8: /lib/libpthread.so.0 (0x7f844647f000+0xf120) [0x7f844648e120] 9: /lib/libc.so.6 (__select+0x13) [0x7f84454b2ef3] 10: /usr/bin/X (WaitForSomething+0x1d2) [0x45d4f2] 11: /usr/bin/X (0x400000+0x30972) [0x430972] 12: /usr/bin/X (0x400000+0x24a0a) [0x424a0a] 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f8445406bbd] 14: /usr/bin/X (0x400000+0x245a9) [0x4245a9] I830PMEvent: Capability change The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server
Hi, On Tue, Apr 12, 2011 at 10:19:27AM -0700, bugzilla-daemon@freedesktop.org wrote: > 0: /usr/bin/X (xorg_backtrace+0x28) [0x45f8a8] > 1: /usr/bin/X (mieqEnqueue+0x1f3) [0x45a523] > 2: /usr/bin/X (xf86PostButtonEventM+0xaa) [0x47ea7a] > 3: /usr/bin/X (xf86PostButtonEvent+0xe5) [0x47ec35] > 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f2be1a49000+0x3f30) > [0x7f2be1a4cf30] > 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f2be1a49000+0x619e) > [0x7f2be1a4f19e] > 6: /usr/bin/X (0x400000+0x6d547) [0x46d547] > 7: /usr/bin/X (0x400000+0x11c459) [0x51c459] > 8: /lib/libpthread.so.0 (0x7f2be4cdd000+0xf120) [0x7f2be4cec120] > 9: /lib/libc.so.6 (writev+0x31) [0x7f2be3d10511] > 10: /usr/bin/X (0x400000+0x69ccc) [0x469ccc] > 11: /usr/bin/X (0x400000+0x619cd) [0x4619cd] > 12: /usr/bin/X (FlushAllOutput+0x139) [0x462599] This implies that your X server is stuck attempting to write to one of its clients; the output buffer could be full. > FATAL: Module fbcon not found. > The XKEYBOARD keymap compiler (xkbcomp) reports: > > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > > Ignoring extra symbols > Errors from xkbcomp are not fatal to the X server > The XKEYBOARD keymap compiler (xkbcomp) reports: > > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > > Ignoring extra symbols > Errors from xkbcomp are not fatal to the X server How are you getting these errors immediately after a backtrace? Have you got any patches applied?
the xkbcomp errors are printed when i switch to terminal and than back to X. they do not seem to be related to the bug. I tested a bit further: the synaptic mieqEnqueue+0x1f3 error always happens when the mouse is misbehaving the first time after starting X. When i use kwin --replace the mouse works ok for a short time and than misbehaving again. this (second) time the error does not show up again.
Patches: - no patches for xf86-input-synaptics - xorg-server: - xorg-server-disable-acpi.patch - xorg-server-1.9-nouveau-default.patch
Created attachment 45553 [details] [review] patch for xorg-server 1.10.0.902
Created attachment 45554 [details] [review] patch for xorg-server 1.10.0.902
This error is also reportet at KDE Bugtracker -> https://bugs.kde.org/show_bug.cgi?id=265734
Is there any work on this bug? I can help with anything if you tell me what information you need.
I am affected, too. If anyone would be working on this bug, I'd be more than happy to provide any details necessary.
also affected by this in debian. old-stable was unaffected. went to stable to get the updated acceleration code in x.org 1.7, but ran into this issue. upgraded to debian/testing/x.org 1.10, and seemed to have fixed the issue on the workstation (nv, x64, dual head, dual card. kensington expert mouse trackball), but did not resolve the issue on the laptop (radeon, i386, saitek ratt/touchpad/trackpoint). using awesome wm on both instances, no gnome/kde services running. xev shows 0 input from mouse when this is triggered. have had this issue occur with only xterm and WM running. natch on anything interesting in the logs. once the focus is 'stuck' on a window, closing that window causes the mouse input to stick to the next focused window. X.Org X Server 1.10.2 evdev driver 2.6.0
following up on this. blacklisting the touchpad input by placing the following into /usr/share/X11/xorg.conf.d/05-touchpadblacklist.conf seems to have fixed this for me (knock on wood): Section "InputClass" Identifier "evdev touchpad blacklist" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Option "Ignore" "on" EndSection granted, this is not a viable solution to the issue for everyone, but may help in diagnosis of what is the root cause. was being hit with this issue within minutes of starting the X server, but since adding the ignore, has been rock solid since my last update 5 days ago.
I have this bug on FreeBSD 8.2, running the latest X server from ports (xorg-server-1.7.7_1,1 and KDE 4.6.5). Specifically, what I am experiencing closely matches comment #61 which Farzad Battiwalla wrote on 2010-08-02 in https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/362359 . In fact, I learned a lot from his description, and I believe this should enable a knowledgeable person to isolate the error. A minor addition to his description: - Once you left-click in a window which has no context menu on a right-click, you are basically stuck. This is for example true for the pin/unpin button in the window border - if you left-click this once, all further mouse events are directed to that button. Even if the mouse can be moved into another window, the balloon help for the pin/unpin button will pop up there once the mouse stops moving. - I can still switch between windows on the current desktop using ALT-TAB. That is to say, the keyboard input will be focused to that window, but not the mouse buttons if the mouse is stuck as described above. - I could get out of the stuck pin/unpin button by using KDE's CTL-ALT-ESC window kill function: Press CTL-ALT-ESC and then RETURN in the window whose pin/unpin button receives the mouse events, and one can then do a right-click hopefully in another window (e.g., the background) with a context menu, which then enables to move the mouse focus to another window by once more right-clicking there (for example the desktop panner of the KDE panel). - In summary, it is possible to redirect the mouse input to a new window if one can manage to bring up a context menu by right-clicking in the window which currently is stuck receiving mouse events, and then right-clicking in the window which one desires to become stuck next. The latter then better have a right-click context menu as well... As I said, Farzad's description is the most accurate one and should enable correction of the problem. I have the problem now for several hours because I am doing a long-running compilation which I do not want to interrupt, and with these instructions I (barely) manage to control my desktop (and write this report). One last comment: I seem to remember (from earlier experiences) that it does not suffice to just restart the X server. Instead, I have to reboot to get rid of the problem for a longer time. Which to me seems to indicate that some hardware register got mangled, or that the X server is accessing some fixed address it shouldn't (maybe usage of already freed stack space?), or whatever. But take this with a grain of salt as I am not sure of this observation.
I changed the platform to All/All, as this happens on Linux and FreeBSD, and on amd64 (original filing) and here on FreeBSD 8.2 i386.
expand the summary to include the words "window focus stuck"
I just had the problem again, and used it to check what has to be restarted in order to resolve it. Note that with careful juggling of right mouse clicks and ALT-TAB (using KDE), even while the problem persists I can address (nearly) every window, or at least kill it, as described in my previous posts. 1. Killing just the X server such that it gets automatically restarted by kdm4 does not resolve the problem. I can log in o.k., but am immediately confronted with mouse events being "stuck" with the first window popping up. 2. Stopping and restarting kdm4 (which also takes down and restarts the X server) -> no resolution, as above. 3. Stopping (in that order) kdm4, hald, dbus, waiting for polkitd, gam_server, and consolekitd to die out, and then restarting dbus, hald, and kdm4 -> no resolution, as above. 4. After 3., one has the process tree shown below: -+= 00001 root /sbin/init -- |--= 00171 root adjkerntz -i |--= 00801 root /sbin/devd |--= 00992 root /usr/sbin/syslogd -s |--= 01036 root dhclient: msk0 [priv] (dhclient) |--= 01037 root /usr/sbin/rpcbind |--= 01157 _dhcp dhclient: msk0 (dhclient) |--= 01158 root /usr/sbin/mountd -r |-+= 01160 root nfsd: master (nfsd) | \--- 01161 root nfsd: server (nfsd) |--= 01168 root /usr/sbin/rpc.statd |--= 01175 root /usr/sbin/rpc.lockd |--= 01248 root /usr/sbin/hcsecd -f /etc/bluetooth/hcsecd.conf |--= 01323 daemon /usr/sbin/rwhod -p |--= 01349 root /usr/local/sbin/cupsd -C /etc/local/cups/cupsd.conf |--= 01370 root /usr/local/sbin/nmbd -D -s /etc/local/smb.conf |-+= 01377 root /usr/local/sbin/smbd -D -s /etc/local/smb.conf | \--- 01423 root /usr/local/sbin/smbd -D -s /etc/local/smb.conf |--= 01518 root /usr/sbin/sshd |--= 01526 root sendmail: accepting connections (sendmail) |--= 01530 smmsp sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) |--= 01537 root /usr/sbin/cron -s |--= 01582 root /usr/sbin/inetd -wW -C 60 |--= 02153 root /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid |--= 02161 root /usr/sbin/ypbind |--= 02171 root /usr/sbin/amd -p -a /... -l syslog /d/auto amd.auto /srcs amd.srcs /users amd.users /vol amd.vol |--= 09653 root /usr/sbin/moused -p /dev/psm0 -t auto |--= 09671 root /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid |-+= 09771 root login [pam] (login) | \-+= 10329 root -zsh (zsh) | \-+= 10389 root pstree | \--- 10390 root ps -axwwo user,pid,ppid,pgid,command |--= 01613 root /usr/libexec/getty Pc ttyv2 |--= 01614 root /usr/libexec/getty Pc ttyv3 |--= 01615 root /usr/libexec/getty Pc ttyv4 |--= 01616 root /usr/libexec/getty Pc ttyv5 |--= 01617 root /usr/libexec/getty Pc ttyv6 \--= 01618 root /usr/libexec/getty Pc ttyv7 If I now also kill the 2 mouse daemons (moused), and then restart them, dbus, hald, and kdm4 -> no resolution, same as above. 5. Rebooting the system resolves the problem. To me this looks like some graphics card register has been incorrectly programmed, maybe one related to detecting cursor movements outside a certain area? I hope this analysis helps some kind soul in resolving the problem. One final remark: When last time the problem occurred, I had a Suse Linux 11.3 running inside a VirtualBox emulator. When I moved the cursor across the vbox, the KDE session within it would behave perfectly normal. That is to say, while the "real" window system exhibited the "stuck window focus for the mouse", the window system in the VirtualBox session was working just fine.
For me this happened xserver-xorg-core 2:1.10.3.902+git20110815+server-1.10-branch.4597f201-0ubuntu0sarvatt~natty Once. After days of running the X server. I downgraded to Xorg 1.10.2.902 (1.10.3 RC 2) and restarted Xorg and so far focus works.
Just saw it once more, and it seems to go away by doing suspend to disk and resume but unplugging and replugging mice and screens does not help.
(In reply to comment #22) > following up on this. blacklisting the touchpad input by placing the > following into /usr/share/X11/xorg.conf.d/05-touchpadblacklist.conf seems to > have fixed this for me (knock on wood): > > Section "InputClass" > Identifier "evdev touchpad blacklist" > MatchIsTouchpad "on" > MatchDevicePath "/dev/input/event*" > Option "Ignore" "on" > EndSection > > granted, this is not a viable solution to the issue for everyone, but may help > in diagnosis of what is the root cause. was being hit with this issue within > minutes of starting the X server, but since adding the ignore, has been rock > solid since my last update 5 days ago. I can confirm that blacklisting the touchpad device effectively prevents the mouse from being stuck. With my synaptics touchpad not being ignored the mouse focus gets stuck quite frequently. ThinkPad-T400, X Server 1.10.1, Ubuntu natty narwal, 2.6.38-11-generic 64 bit
the problem is fixed for me with current(5.10.11) git xf86-input-synaptic drivers. Maybe this is fixed in version 1.5.0 too, but this version is not availible in portage (gentoo).
Marking as fixed based on previous comment.
This bug is not fixed. I'm using Xorg-server 1.12.3 xf86-input-synaptics 1.6.2 xfce 4.10 OSS nvidia driver opensuse 12.2 x86-64 I can untrigger the bug by un- and replugging my wireless mouse-receiver (Logitech).
I've been using Linux for years on this same hardware and never had this issue. Last month I upgraded to Kubuntu 12.10 trough a fresh install, and I now have this issue. And I have it a lot. It happens at every boot, and then randomly many times a day. It can take hours before it happen again, or a second. I've never experienced such a disabling bug. The bug was reported on many platforms as far back as 2009, but the source still hasn't been found, how's that even possible? Has nobody done a study to see what every report has in common? Many desktop users reported this bug, so this rules out a synaptic problem. I've also never had issues with this laptop before, so it's obviously a software problem. Dell Vostro 1500 Synpatic touchpad, Logitech G5 mouse, Kensington Expert Mouse Kubuntu 12.10 X86_64 KDE 4.9.4 Xorg 7.7 Xorg server 1.13.0 xserver-xorg-input-synaptics 1.6.2 I tried every single Nvidia driver available, without result.
I din't have this problem on Kubuntu 12.10 x86-64... ...until I upgraded to KDE 4.10 from Kubuntu Backports PPA Using xorg-edgers PPA.
By the way, the problem appears ONLY when I plug in my Logitech Unity receiver for my Performance MX mouse. If I only work w/ touchpad this bug is non-existent.
Today I formatted my drive and installed Fedora 18 KDE. The problem showed up within seconds after the first boot. I didn't change any settings, didn't install any package. It's just insane how this crippling bug can affect both most popular distributions. And I NEVER had such problems before, using the same hardware. Preliminary testing seems to confirm that the bug is not present when I unplug my logitech mouse. Though with the random behaviour of this bug, it's hard to tell.
I can confirm that the bug is only present when my Logitech G5 mouse is plugged. Testing these past few days seem to suggest that the focus gets stuck only when I _use_ my Logitech mouse. In other words, if I leave the Logitech plugged but only use my laptop's trackpad or my Kensington trackball, the focus never gets stuck. Then the moment I move the Logitech mouse, without clicking anywhere, the focus gets stuck. Furthermore, once the focus gets stuck, it is instantly freed by unplugging the Logitech mouse. Plugging the Logitech mouse back in instantly locks the focus to an object. The only reliable method I found for freeing it is to switch terminal (tty). Today I brought my Logitech mouse to college and tried it on a PC running Windows 7. Within seconds of using my mouse, the focus got stuck. That's right: the exact same problem described by this bug report is present in Windows 7. Hitting Ctrl+Alt+Del and then Cancel freed the focus until it got stuck again. Same thing as switching terminal under Linux. I really don't see how this could be possible. The only explication I can see is that the firmware inside the mouse somehow got corrupt. I tried to flash it from school, but Logitech only has flash tools that works in Windows XP. So until I can find a computer that still runs XP, I cannot confirm this theory.
I can reproduce this very easily using the following steps. load a youtube video (which uses flash) right click outside the flash player (context menu shows up) left click outside the flash player (hide context menu) right click inside the flash player (context menu 2 shows up) left click outside the flash player (hide context menu 2) left click inside the flash player (give focus to flash player) left click outside the flash player (context menu 2 shows up) Expected results for the very last step however are that context menu shows up This is not flash related. I have pictures attached showing how clicking on my terminal with the right mouse button brings up a firefox context menu. This is reproducible for me on Debian 7 amd64 with the latest Xorg, and openbox. It is also reproducible on backtrack 5 r3 with kde4, however at this point I'm guessing this is reproducible on nearly everything. I'm using a large lcd as my monitor. I'm not sure if this has anything to do with anything. I will attach three images below. r5@phenom:~$ echo $(< /etc/issue); Xorg -version Debian GNU/Linux 7.0 \n \l X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian Current Operating System: Linux phenom 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=UUID=b5af0983-5a48-4a2c-92d0-878603438b9a ro quiet Build Date: 23 February 2013 02:40:45PM xorg-server 2:1.12.4-5 (Julien Cristau <jcristau@debian.org>) Current version of pixman: 0.26.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. r5@phenom:~$
The very last step should have said right click outside the flash player (context menu 2 shows up)
Created attachment 75474 [details] Wrong context menu shown due to focus not switching.
Created attachment 75475 [details] Wrong context menu shown due to focus not switching.
Created attachment 75476 [details] Wrong context menu shown due to focus not switching.
Created attachment 75477 [details] Wrong context menu shown due to focus not switching.
Created attachment 75478 [details] Wrong context menu shown due to focus not switching.
Created attachment 75479 [details] Wrong context menu shown due to focus not switching.
This bug seems to be very closely related to the mouse being used. I just tried reproducing it with another mouse and simply could not reproduce no matter how hard I tried. Three seconds later, with my initial mouse, I can reproduce the issue every single time I try. Switch the mouse again ... and can't reproduce. The mouse that doesn't work is ione lynx-r5 The mouse is complete garbage anyway and this just gives me a closing argument to putting it in the trash.
I just added the following kernel parameters noapic acpi=off and I can no longer reproduce this issue.
I really should have waited a little and put all my findings in out big post, but I expect this to be the last finding. Starting with noapic acpi=off as mentioned above fixes this issue. However, even with these added boot parameters, unplugging and replugging the mouse will re-expose this bug. Booting without the mentioned kernel parameters always exposed the bug.
I also have this bug and would be interested in helping isolate it or in testing patches. distro: Ubuntu 12.04 or Debian wheezy desktop: Unity or Gnome 3 mouse: Cyborg R.A.T. 7 video: GeForce GTX 670 Observed behavior is that the mouse stops working on first login after I have at least two windows up. If I close those windows (^D or the like) and log out (effectively restarting X) the problem does not return until my next reboot. I have not experimented with the other triggering mechanisms yet (unplugging and re-plugging mouse, for example), but will be happy to try whatever.
Sorry, to be even more clear, "the problem" refers to one window receiving all mouse events regardless of where the mouse is. If a terminal gets the focus and I Alt-tab to Chromium, obscuring the terminal, I can select text in the terminal by click-dragging in the Chromium window.
I can now reproduce this at will. I recently got an IOGear KVM. The bug is triggered every time I switch back to my Ubuntu machine. Please let me know if there's anything I can do to provide useful debugging information. I am comfortable applying patches and building packages if necessary.
I've been able to reproduce this by opening a terminal, then opening mouse settings. By removing my G930 headset USB dongle however, the problem doesn't happen. Each time I open mouse settings with the dongle, the problem happens, and each time I open the settings without the dongle everything is fine.
I can confirm this issue on a Thinkpad T420, both on a freshly installed Ubuntu 14.10 and Kubuntu 14.10. It first occured shortly (but not immediately) after enabling the touchpad in the bios. Reinstalling the system or running from a live usb did not fix it. After disabling the touchpad again in the bios, the problem was gone immediately.
I'm on openSUSE 13.1, and just started getting this bug again after installing some online updates. The list of RPMs installed in the recent batch is: libreoffice-calc-extensions-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:05 AM MST libreoffice-base-extensions-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:05 AM MST libreoffice-base-drivers-mysql-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:05 AM MST flash-player-kde4-11.2.202.424-78.1.x86_64 Thu 11 Dec 2014 09:41:05 AM MST flash-player-11.2.202.424-78.1.x86_64 Thu 11 Dec 2014 09:41:05 AM MST libreoffice-mailmerge-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-impress-extensions-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-filters-optional-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-draw-extensions-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-calc-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-base-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:04 AM MST libreoffice-draw-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:03 AM MST libreoffice-writer-extensions-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:02 AM MST libreoffice-pyuno-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:02 AM MST libreoffice-math-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:02 AM MST libreoffice-kde4-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:02 AM MST libreoffice-impress-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:02 AM MST libreoffice-help-en-US-4.1.6.2-33.2.noarch Thu 11 Dec 2014 09:41:02 AM MST mozilla-nss-32bit-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:41:01 AM MST libreoffice-writer-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:41:01 AM MST MozillaFirefox-34.0.5-50.3.x86_64 Thu 11 Dec 2014 09:41:00 AM MST libreoffice-4.1.6.2-33.2.x86_64 Thu 11 Dec 2014 09:40:56 AM MST python-devel-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:51 AM MST mozilla-nss-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:51 AM MST libsoftokn3-32bit-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:51 AM MST libreoffice-icon-theme-crystal-4.1.6.2-33.1.noarch Thu 11 Dec 2014 09:40:51 AM MST python-xml-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:50 AM MST python-tk-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:50 AM MST python-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:50 AM MST libsoftokn3-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:50 AM MST libreoffice-icon-theme-galaxy-4.1.6.2-33.1.noarch Thu 11 Dec 2014 09:40:50 AM MST libfreebl3-32bit-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:50 AM MST python-base-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:49 AM MST mozilla-nss-certs-32bit-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:49 AM MST mozilla-nss-certs-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:49 AM MST libreoffice-icon-theme-hicontrast-4.1.6.2-33.1.noarch Thu 11 Dec 2014 09:40:49 AM MST dbus-1-x11-1.8.12-4.28.2.x86_64 Thu 11 Dec 2014 09:40:49 AM MST dbus-1-1.8.12-4.28.2.x86_64 Thu 11 Dec 2014 09:40:49 AM MST yast2-samba-server-3.0.4-2.4.1.noarch Thu 11 Dec 2014 09:40:48 AM MST tar-1.26-19.12.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST pm-utils-1.4.1-33.9.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST openvpn-2.3.2-3.4.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST mozilla-nspr-4.10.7-19.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST mozilla-nspr-32bit-4.10.7-19.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST libFLAC++6-1.3.0-2.4.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST flac-1.3.0-2.4.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST dhcp-client-4.2.5.P1-0.6.17.1.x86_64 Thu 11 Dec 2014 09:40:48 AM MST libreoffice-icon-theme-oxygen-4.1.6.2-33.1.noarch Thu 11 Dec 2014 09:40:47 AM MST libpython2_7-1_0-32bit-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libpython2_7-1_0-2.7.6-8.22.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libfreebl3-3.17.2-47.2.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libFLAC8-32bit-1.3.0-2.4.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libFLAC8-1.3.0-2.4.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libdbus-1-3-32bit-1.8.12-4.28.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST libdbus-1-3-1.8.12-4.28.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST dhcp-4.2.5.P1-0.6.17.1.x86_64 Thu 11 Dec 2014 09:40:47 AM MST
Never mind; fixed it by unplugging and replugging my Logitech mouse, as suggested in this thread: https://forum.kde.org/viewtopic.php?t=95319 So mine might have been a simpler issue.
I just upgraded to Ubuntu 15.04 and can no longer reproduce this bug. My xorg package is 1:7.7+7ubuntu4. As far as I know the upgrade is the only change I've made to my desktop since the last time I could reproduce the bug. I hope this new information is helpful. I'd still be happy to help out with further testing or by providing more information about my hardware and software.
Sorry, I just remembered I had turned off sloppy focus because Steam doesn't play well with it. I went ahead and turned sloppy focus back on and I still can't reproduce the bug at will (by unplugging and re-plugging-in my mouse). I will of course post here again if I ever do see the bug again.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.