While building my own xkb config file, I managed to make AltGr
dysfunctional. Bottom line is: Removing this three lines (one is actually a whole block) ...
xkb_keymap {
xkb_keycodes "whatever" {
[...]
>>>> <LVL3> = 92;
[...]
};
[...]
xkb_symbols "anything" {
[...]
>>>> key <LVL3> { [ ISO_Level3_Shift ] };
>>>> modifier_map Mod5 { <LVL3> };
... created the problem and re-adding them made the problem disappear, now AltGr
works as expected again. So, problem is: My keyboard doesn't have a key producing key code 92 at all (that's the reason for me to remove those lines in the first place). Now, I figured it out while running xev
with two keyboards connected (one with system's default keyboard layout and thus working AltGr
and the other with my broken xkb file) and playing around with the two AltGr
keys, until I suddenly noticed this line:
KeyPress event, serial 53, synthetic NO, window 0x3000001,
root 0x4b1, subw 0x0, time 2986451693, (63,136), root:(716,408),
state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
>>>> XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
That was the reason for me to try re-adding those lines.
Now the question: Why is that key remapped to keycode 92 and where does that happen? (Since I didn't have any definition for that key in my file any more, my file was innocent ;)