Bug 607150 - Mouse button never releases when xkb PointerKeys are used
Summary: Mouse button never releases when xkb PointerKeys are used
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-server
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Peter Hutterer
QA Contact: desktop-bugs@redhat.com
Keywords: Triaged
Depends On: 618422
Blocks: 508787
TreeView+ depends on / blocked
Reported: 2010-06-23 11:30 UTC by Mauricio Teixeira
Modified: 2010-11-10 21:59 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2010-11-10 21:59:06 UTC

Attachments (Terms of Use)

Description Mauricio Teixeira 2010-06-23 11:30:00 UTC

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.

Possible workarounds:

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.

Logs checked:

- When the bug happens, nothing is appended to either messages, Xorg.0.log or 
user's .xsession-errors.

Comment 3 RHEL Product and Program Management 2010-06-23 11:52:52 UTC
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

Comment 6 Matěj Cepl 2010-06-24 16:06:54 UTC
What I meant is that this probably RHEL duplicate of this Fedora bug 603953. There is some analysis there.

Comment 7 Peter Hutterer 2010-06-24 22:44:49 UTC
Possibly a dupe of the RHEL bug  607410. Need to verify this though.

Comment 8 Peter Hutterer 2010-06-25 07:00:19 UTC
Definitely 603953, not 607410.

Comment 9 Peter Hutterer 2010-06-29 06:32:26 UTC
Renaming, this isn't a grab issue but a stuck button when PointerKeys are in use.

Comment 10 Peter Hutterer 2010-06-30 01:13:52 UTC

xorg-x11-server-1.7.7-17.el6 is available in brew

Comment 12 Peter Hutterer 2010-07-07 02:31:15 UTC
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.

Comment 14 Peter Hutterer 2010-07-09 00:31:34 UTC

xorg-x11-server-1.7.7-19.el6 is available in brew

Comment 16 Peter Hutterer 2010-07-23 03:54:18 UTC
Reopening again...

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.

Comment 17 Peter Hutterer 2010-07-26 21:57:00 UTC
Moving back to ON_QA per caillon's request. Bug 618422 filed instead.

Comment 18 Radek Lat 2010-08-18 13:39:25 UTC
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.

Comment 19 releng-rhel@redhat.com 2010-11-10 21:59:06 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.