Bug 1161061

Summary:	Xephyr: caps-lock persistent after leaving window
Product:	Red Hat Enterprise Linux 6	Reporter:	Marian Csontos <mcsontos>
Component:	xorg-x11-server	Assignee:	Olivier Fourdan <ofourdan>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	6.6	CC:	ofourdan, tpelka
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-22 05:51:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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