This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AltGr key mostly fires an additional CONTROL key


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]