Re: AltGr key mostly fires an additional CONTROL key

[Jon TURNEY <jon.turney@dronecode.org.uk>]

On 31/07/2011 19:53, Paul Maier wrote:
> Hi Jon,
>
> another issue with the keyboard on a Lenovo T60 (Windows XP) and
> Lenovo T510 (Windows 7).
>
> The AltGr key mostly fires and locks (!) an additional CONTROL key press.
> This makes the AltGr key basically inusable (and a xmodmap workaround is not
> possible).
>
> The AltGr key is a modifier key e. g. needed to get the @ sign (AltGr + Q) on a
> German keyboard.
>
>
> This is, what I found out on this issue:
> ----------------------------------------
>
> This is the output of xev when that occured. I pressed AltGR+Q once and
> released it again.
> Then (without any other modifier key pressed) I hit once a normal A.
> As you can see, instead of a @ I get a CONTROL-@ (= control character 00) and
> instead of an a I get a CONTROL-A (= control character 01).
> xev logs out very clear that there is an additionally (unwanted) KeyPress for
> key 37 = CONTROL_L.
> There is no KeyRelease for the keycode 37 = CONTROL_L in the log:
>
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32794468, (47,57), root:(73,99),
>      state 0x10, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795046, (47,57), root:(73,99),
>      state 0x90, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795531, (47,57), root:(73,99),
>      state 0x94, keycode 24 (keysym 0x40, at), same_screen YES,
>      XLookupString gives 1 bytes: (00) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795640, (47,57), root:(73,99),
>      state 0x94, keycode 24 (keysym 0x40, at), same_screen YES,
>      XLookupString gives 1 bytes: (00) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32798390, (47,57), root:(73,99),
>      state 0x94, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32799890, (47,57), root:(73,99),
>      state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
>      XLookupString gives 1 bytes: (01) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32800015, (47,57), root:(73,99),
>      state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
>      XLookupString gives 1 bytes: (01) ""
>      XFilterEvent returns: False
>
>
> The ISO_Level3_Shift without the additional Control_L (left control key) would
> be the expected behaviour.
> It happens quite often (but I couldn't find the rule behind), pressing the
> AltGr ONCE also LOCKS the Control_L key in a way that if you later press a
> normal letter, say: a normal c, you get a CONTROL-C into the application.
> The Control_L (left control key) stays locked until you press the real CONTROL
> key.

>
> Meanwhile XWin.0.log logs out this:
>
> [ 32804,781] winSendKeyEvent: dwKey: 105, fDown: 1, nEvents 2
> [ 32805,984] winTranslateKey: wParam 00000011 lParam e01d0001
> [ 32805,984] winSendKeyEvent: dwKey: 29, fDown: 0, nEvents 2
> [ 32805,984] winTranslateKey: wParam 00000012 lParam c1380001
> [ 32805,984] winSendKeyEvent: dwKey: 105, fDown: 0, nEvents 2
> [ 32809,859] winTranslateKey: wParam 00000041 lParam 001e0001
> [ 32809,859] winSendKeyEvent: dwKey: 30, fDown: 1, nEvents 2
> [ 32809,968] winTranslateKey: wParam 00000041 lParam c01e0001
> [ 32809,968] winSendKeyEvent: dwKey: 30, fDown: 0, nEvents 2
>
> Key 29 seems to be the stuck control key.
> To emphasize again, I didn't press the control key on my keyboard.
> I just pressed AltGr Q (in the intention to get a @), released it again, then I
> pressed "a".

Thanks for the detailed report.

The actual issue here is that Windows apparently inserts a fake Ctrl-L 
keypress/release when AltGr is pressed/released (except when the keyboard 
layout is US).  I have never found any documentation of this behavior, and 
I've no idea why it does this.

There is some code in the X server which attempts to detect and discard these 
fake keypress/release events, but it not working reliably for some people has 
been reported a few times, but I've never been able to reproduce the problem 
or get to the bottom of what causes it.

If you are willing to help, I've put together a test build with some extra 
debugging at [1].  If you could run that with '-logverbose 3' as before and 
attach the output, that would be helpful.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/