Bug 607150
| Summary: | Mouse button never releases when xkb PointerKeys are used | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Mauricio Teixeira <mteixeira> |
| Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | desktop-bugs <desktop-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | istojmir, rlat, syeghiay |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 21:59:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 618422 | ||
| Bug Blocks: | 508787 | ||
|
Description
Mauricio Teixeira
2010-06-23 11:30:00 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 inclusion. 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. MODIFIED 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. 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. MODIFIED xorg-x11-server-1.7.7-19.el6 is available in brew 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. 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. |