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".