Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The following problem happens occasionally (probably once week) on my system: Out of the sudden the left mouse button stops working: - right and middle buttons still work - all attached mice show the same problem - otherwise the X still seems to be running fine Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.7.6-4.fc12.i686 How reproducible: - happens occasionally, but often enough to be quite annoying ;-) Steps to Reproduce: n/a just happens Additional info: I have debugged the problem a little bit and I believe that I could narrow it down to the "Virtual core XTEST pointer": $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Macintosh mouse button emulation id=8 [slave pointer (2)] ⎜ ↳ Logitech USB RECEIVER id=11 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=7 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=12 [slave keyboard (3)] ↳ Power Button id=13 [slave keyboard (3)] ↳ Logitech USB Receiver id=6 [slave keyboard (3)] ↳ USB Keyboard id=9 [slave keyboard (3)] ↳ USB Keyboard id=10 [slave keyboard (3)] Then I checked the state of the buttons for all pointer input devices and for id=4 (Virtual core XTEST pointer) the mouse button was stuck and "down" (all buttons of the physical mice were correctly released): $ xinput query-state 4 2 classes : ButtonClass button[1]=down button[2]=up button[3]=up button[4]=up button[5]=up button[6]=up button[7]=up button[8]=up button[9]=up button[10]=up ValuatorClass Mode=Relative Proximity=In valuator[0]=640 valuator[1]=512 How the button of a (virtual?) input device could get stuck I don't know at all. I could recover using the following workaround: $ xinput list-props 4 Device 'Virtual core XTEST pointer': Device Enabled (115): 1 XTEST Device (229): 1 $ xinput set-int-prop 4 115 8 0 $ xinput list-props 4 Device 'Virtual core XTEST pointer': Device Enabled (115): 0 XTEST Device (229): 1
I believe I am also observing this problem. I shall verify this with the xinput tricks the next time if occurs.
I also occasionally observe this problem since some months, and I get the same output from "xinput query-state 4". In these days I am starting suspecting that it is connected to the "Mouse Keys" option of the keyboard Preferences, so, if you are using Gnome desktop, please check whether in System->Preferences->Keyboard->"Mouse Keys" tab the option "Pointer can be controlled using the keypad" is set, if this is the case, this is probably the reason for the problem. I set this feature just for test (I rarely use keypad) at time of Fedora 8, and forgot about it. Now I notice that, if that option is set, the problem described can be reproduced hitting the "Ins" key on the keypad - the mouse button virtually stays pressed - I wonder whether this is the correct behavior of "Mouse Keys" or not (I cannot find the detailed documentation of this feature in Gnome help), but in the past I did not notice it. By Pressing the neighbouring "Del" key or playing around with other keypad keys, it is possible to restore normal behavior (also according to xinput query-state 4).
*** Bug 622473 has been marked as a duplicate of this bug. ***
Mouse Keys was not enabled on my system yet the problem still occurs.
Well, after I disabled "Mouse Keys" i did not notice the problem anymore, so the reason was probably different from yours; unfortunately I cannot help further.
(In reply to comment #2) > In these days I am starting suspecting that it is connected to the "Mouse Keys" > option of the keyboard Preferences, so, if you are using Gnome desktop, please > check whether in > > System->Preferences->Keyboard->"Mouse Keys" tab > > the option "Pointer can be controlled using the keypad" is set, if this is the > case, this is probably the reason for the problem. Yes, that was the problem. The feature can be also turned on/off using Shift+NumLock and it seems that I press this key combination accidently sometimes... I have read a couple of similar reports and so I'm wondering whether it is wise to use this key combination since the user has no feedback whether this feature is activated... I leave it up to the maintainers whether there is now any need for action... (In reply to comment #4) > Mouse Keys was not enabled on my system yet the problem still occurs. Klaus, whenever the problems happens for you again, please can you try the commands I wrote in the original description of this bug report to verify whether you see exactly the same issue? If it is not the same problem, please open another bug report.
I can reliably reproduce this behavior (which, now that I understand what's happening, I concede is a feature, not a bug) by enabling "Pointer can be controlled using the keypad", either through the menu or by hitting Shift-NumLock, and then hitting the '0' key on the keypad. I can get control of the mouse buttons back by pressing '5' on the keypad. I do, however, consider the lack of feedback about whether that option is enabled to be a bug. Until I realized what was going on, it resulted in the loss of mouse control requring a logout/login. This BZ also explains why my keypad appeared to be non-functional at times, since the defaults are such that a quick keypress will not cause the mouse to move noticeably unless you happen to be looking directly at the pointer. I am very much not a UI person, but I have two ideas about how I might have had a better idea what was going on: 1) Would it be acceptable to put an icon somewhere on the screen to show that "Pointer can be controlled using the keypad" is enabled? I realize screen real-estate is precious, but I don't see a lot of ways to indicate to the user what's happening. 2) If it's enabled through the Shift-NumLock keypress, which I assume I hit accidentally to turn it on on my system, put up a confirmation dialog. A user can then hit either Esc or Enter to cancel or confirm.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
The issue is still present in F13 and F14: Even if we know already the explanation, it seems to happen occasionally that people are hit by the problem since they accidentally turn on the "Mouse keys" mode. As Dave already said, there is no indication at all when this mode is turned on. This mode can be dangerous, because if the mode is active and "Ins" is pressed on the keypad, the user can't use the left mouse button anymore without knowing why... Turning off the "Mouse Keys" feature in the Keyboard Preferences doesn't help, because this item reflects directly the status of this feature. So if I turn it on via "Shift+Num Lock" it is turned on in the dialog as well (and vice versa for turning it off). I haven't even found an option in the Keyboard Layout Options to disable the behaviour of "Shift+Num Lock" completely. The issue demonstrates a very bad usability... Either it should be fully turned off so that accidentally entering the mode would not be possible or there should be a clear indication when the "Mouse Keys" mode is active.
This bug was filed against Fedora 14 which is now EOL. Please re-open this bug if you still experience this issue with one of the currently suppported versions of Fedora. Don't forget to update the version field if you do so.
Brief testing suggests that Fedora 17 no longer enables shift-NumLock to turn Mouse Keys mode on, so IMO this is no longer an issue since I can't see how I could accidentally enable it. Mouse Keys can still be enabled from the universal access control panel.
Hello guys, This issue is still actual for Fedora 28. What information do you need for analysis? I have almost 100% reproducibility after few minutes from system start (and with Ubuntu as well) I tested this on HP ProBook 4340s if this has a sense.