Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 607150 - Mouse button never releases when xkb PointerKeys are used
Mouse button never releases when xkb PointerKeys are used
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-server (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Peter Hutterer
desktop-bugs@redhat.com
: Triaged
Depends On: 618422
Blocks: 508787
  Show dependency treegraph
 
Reported: 2010-06-23 07:30 EDT by Mauricio Teixeira
Modified: 2010-11-10 16:59 EST (History)
3 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.7.7-17.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 16:59:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mauricio Teixeira 2010-06-23 07:30:00 EDT
Hi,

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
off).
- 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 07:52:52 EDT
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
inclusion.
Comment 6 Matěj Cepl 2010-06-24 12:06:54 EDT
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 18:44:49 EDT
Possibly a dupe of the RHEL bug  607410. Need to verify this though.
Comment 8 Peter Hutterer 2010-06-25 03:00:19 EDT
Definitely 603953, not 607410.
Comment 9 Peter Hutterer 2010-06-29 02:32:26 EDT
Renaming, this isn't a grab issue but a stuck button when PointerKeys are in use.
Comment 10 Peter Hutterer 2010-06-29 21:13:52 EDT
MODIFIED

xorg-x11-server-1.7.7-17.el6 is available in brew
Comment 12 Peter Hutterer 2010-07-06 22:31:15 EDT
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.

Reproducer:
- 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-08 20:31:34 EDT
MODIFIED

xorg-x11-server-1.7.7-19.el6 is available in brew
Comment 16 Peter Hutterer 2010-07-22 23:54:18 EDT
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:
http://lists.freedesktop.org/archives/xorg-devel/2010-July/011355.html

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 17:57:00 EDT
Moving back to ON_QA per caillon's request. Bug 618422 filed instead.
Comment 18 Radek Lat 2010-08-18 09:39:25 EDT
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 16:59:06 EST
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.