Bug 1161061 - Xephyr: caps-lock persistent after leaving window
Summary: Xephyr: caps-lock persistent after leaving window
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-server
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Olivier Fourdan
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-06 10:11 UTC by Marian Csontos
Modified: 2015-07-22 05:51 UTC (History)
2 users (show)

Fixed In Version: xorg-x11-server-1.15.0-31.el6
Doc Type: Bug Fix
Doc Text:
The keyboard remained in Caps Lock or Num Lock mode even after the keys were pressed again to change input mode. Now, the Caps Lock and Num Lock functions no longer remain active after pressing the keys to deactivate them.
Clone Of:
Environment:
Last Closed: 2015-07-22 05:51:05 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1445 normal SHIPPED_LIVE xorg-x11-server bug fix and enhancement update 2015-07-20 18:44:00 UTC

Description Marian Csontos 2014-11-06 10:11:53 UTC
Description of problem:
In Xephyr with focus follows mouse caps-lock is sometimes "sticky" and can not be simply turned off. Same for num-lock. And it can be quite tricky to turn it off. The problem is the key-up event is never delivered to the client.

The question is should it? To that I answer at least in case of Caps and Num lock resounding yes, as these are global state keys and there is also a precedent in the spice-client Bug 679467 (I know this is not a court-room case but the rule is IMHO appropriate here).

But at least it works for modifier keys (Shift, Alt and Control) so one does not (often) kill application in selinux sandbox with `w` or `q` keys but some applications (e.g. Firefox with or without vimperator plugin) are rather sensitive to caps-lock and one can close whole window instead of a tab and other nasty things.

Looks like for me the best option it will be to disable the caps-lock all together and rely on vim's gU :-)

Version-Release number of selected component (if applicable):
xorg-x11-server-Xephyr-1.15.0-22.el6.x86_64
kernel-2.6.32-504.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
Prepare:
1. setup focus follows mouse
2. start xterm in Xephyr
    (/usr/bin/Xephyr -terminate -screen 800x600 -dpi 96 -displayfd 5 5>&1 2>/dev/null) | while read D; do DISPLAY=:$D xterm & done
Test:
1. focus into Xephyr window
2. press Caps-lock down
3. move mouse out of Xephyr window so it loses focus
4. release Caps-lock
5. caps-lock in Xephyr window remains in effect regardless how many times the key is pressed.
Workaround:
To turn caps-lock off repeat steps 1-4.

Things get more complicated once caps-lock is turned on (both down and up) outside of window, cursor is moved into the window, caps-lock turned off (both down and up) and the caps-lock in the client will remain in effect.

Actual results:
- caps-lock in Xephyr window remains in effect regardless how many times the key is pressed

Expected results:
- caps-lock should be turned off (at least when pressed and released in the client)

Additional info:

Comment 8 errata-xmlrpc 2015-07-22 05:51:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1445.html


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