Sorry if I choose the wrong product, but this bug is so weird that I don't even know where to start debugging it.
A few days ago I notice that at random times of the day my mouse pointer
would lock as if it was clicked somewhere and never released. That
prevented me from using my graphical environment, so I had to go to a console
(CTRL+ALT+F2) and gdm-stop.
Today, this bug happened again, and I suspected it was possible to reproduce.
Playing around a bit, I was able to reproduce easily, and even find some
workarounds, but I don't understand where the problem is or how to fix.
What I used to reproduce:
- RHEL 6 Snapshot 6 installed in English.
- Laptop Lenovo T60W with English keyboard (but some co-workers were able to
reproduce with T61 and T400 with different keyboard types)
- External full English keyboard (with numeric keypad, does not matter if direct
connected to USB, or via docking station, I tested Logitech and IBM).
How to reproduce:
- Log in.
- Never mind about the NumLock (it will make no difference if it's on or
- Open gedit (or any other application, it does not matter).
- Move the mouse pointer to the window title bar.
- Hit 0/ins on the numeric keypad.
- Move the mouse, and you will see it grabbed the window, and no matter
what you do, it will never release.
- Hit 0/ins twice, then hit ./del (dot).
- Mouse pointer is released.
a) Login without the keyboard; or
b) After login, disconnect the keyboard, and connect again.
Doing any of the above will make the keyboard act as expected.
Never do this:
- If you disconnect and re-connect the keyboard with the pointer
grabbed, the numeric keypad will work, but the mouse pointer will never
ungrab, and you will have to gdm-stop.
- When the bug happens, nothing is appended to either messages, Xorg.0.log or
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
What I meant is that this probably RHEL duplicate of this Fedora bug 603953. There is some analysis there.
Possibly a dupe of the RHEL bug 607410. Need to verify this though.
Definitely 603953, not 607410.
Renaming, this isn't a grab issue but a stuck button when PointerKeys are in use.
xorg-x11-server-1.7.7-17.el6 is available in brew
Moving back to ASSIGNED
The current behaviour, while correct, can lead to an unresponsive mouse. The server assumes that buttons pressed will be released and that while a button is pressed this is intentionally so.
PointerKeys buttons may be pressed accidentally, or XTEST button events may be send unsynchronised by a client. Two use-cases:
- PointerKeys is enabled and the user accidentally hits 0 on the numpad. this causes the button to be logically down and remain down until 1 on the numpad is pressed. If the press is accidentally, the perceived behaviour is a stuck button.
- A client sends an XTEST button event, but does not send a button release event. The button remains down, perceived behaviour is again a stuck button.
In earlier server versions a physical button press would release a logical button press caused by XTEST or PointerKeys. This behaviour should be restored, and in fact it has been restored upstream already.
- hit Shift+NumLock to enable PointerKeys
- hit 0/Ins on the keypad and pretend it was done without noticing.
- try to use the mouse - button is stuck down.
Requesting exception, this is a serious problem.
xorg-x11-server-1.7.7-19.el6 is available in brew
The last fix introduced a regression in the handling of devices with more than two axes. A full description of (and proposed fix for) the issue is available here:
Reproducible by using e.g. a wacom tablet and generating button releases on the tablet - the log will fill up with "too many valuators" error messages.
Moving back to ON_QA per caillon's request. Bug 618422 filed instead.
Tested and Verified on xorg-x11-server-1.7.7-23.el6.
When PointerKeys are enabled, hitting 0/Ins on the keypad grabs a window but pressing any HW mouse key releases it.
Moving to VERIFIED.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.