Bugzilla – Bug 19602
ALT-GR switch on german keyboard layout behaves weird
Last modified: 2009-07-09 18:48:12 UTC
Created attachment 22026 [details]
10-x11-input.fdi hal keyboard configuration
After I moved to the git releases (*-9999) of xorg and all it's xf86-* drivers I noticed that the ALT-GR switch in order to write some special characters as the "@" symbol (ALT-GR + q) weren't working anymore.
The weird thing about it is that xev tells me the correct mappings as seen in the above example:
Pressing ALT-GR + q:
KeyPress event, serial 33, synthetic NO, window 0x1000001,
root 0x8b, subw 0x0, time 49458232, (283,507), root:(341,585),
state 0x88, keycode 24 (keysym 0x40, at), same_screen YES,
XLookupString gives 1 bytes: (40) "@"
XmbLookupString gives 1 bytes: (40) "@"
XFilterEvent returns: False
Only pressing ALT-GR:
KeyPress event, serial 30, synthetic NO, window 0x1000001,
root 0x8b, subw 0x0, time 49665645, (465,460), root:(523,538),
state 0x0, 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
But is unusable in all my X applications. After some research I noticed, that if pressing first ALT-GR + 8 (the "[" symbol) and directly following e.g. ALT-GR + q in all my favored x-terminals (aterm, xterm, rxvt-unicode) the keys get visible in this term. This is not reproducible in other applications, too. In opera e.g. I can't use this weird ALT-GR switch method at all.
I've attached HAL's keyboard configuration file.
Created attachment 22027 [details]
Attached my Xorg.log
do you see the same problem when running setxkbmap -layout de -variant nodeadkeys? At least that command seems to work fine here.
(In reply to comment #2)
> do you see the same problem when running setxkbmap -layout de -variant
> nodeadkeys? At least that command seems to work fine here.
Ok, that seems to work. But I don't see, why it worked with former - "stable" - releases just out of the box and now it just forgot about this layout/variant configuration derived from HAL. The nodeadkeys entry, I deleted today from my hal configuration as it seemed there were no changes, if it was present or not.
I've now added setxkbmap (-layout de -variant nodeadkeys) to my autostart script and think this bug can be marked as solved now.
Thank you very much, Peter.
*** Bug 19401 has been marked as a duplicate of this bug. ***
This isn't really fixed, we still need to figure out why the settings don't get taken. Reopening.
If you need some help, let me know, how i could help with this problem :)
Actually, yes. Please attach the output of "xkbcomp -xkb :0 -" after and
before running setxkbmap (i.e. once when it works, once when it doesn't).
just looked at that, with the current master tree and it seems to work fine. are you running a DE that might mangle it? when you start plain X with an xterm only, does it work then?
a short update: i can confirm that it's broken. tested with the german layout.
interestingly enough, it works after being set with setxkbmap -layout de but it does not work when set by GNOME or xkbcomp directly. looking at the output after the successful setxkbmap it looks like some memory screwup in the server that just happens to produce the right result. Don't know the cause of it yet.
bisected to 61c508fa78aa08ea2666fde950fbafad95d65056.
Author: Daniel Stone <firstname.lastname@example.org>
AuthorDate: Fri Apr 25 19:47:16 2008 +0300
XKB: Sanitise vmods in actions
Turn vmods from two unsigned chars into one int.
what a mess. the four "XKB: Sanitise ..." commits changed the struct sizes for various XkbAction structs. Since we read from the wire into the struct and vice versa this caused wrong offsets, etc.
Even with the headers fixed up that the struct sizes are the same client/server side it still was broken. There is some magic going on internally and I have no idea where it actually breaks - each struct is copied, resized, etc several times.
I've reverted the patches and pushed.
Revert "XKB: Sanitise * actions" commits (#19602)
Reverts the following four patches:
feb757f384382c7782ceac55 "XKB: Sanitise vmods for redirected keys"
b5f49382fe48f0a762d9a15f "XKB: Sanitise ctrls action"
1bd7fd195d85681e722161f8 "XKB: Sanitise pointer actions"
61c508fa78aa08ea2666fde9 "XKB: Sanitise vmods in actions"
Strictly speaking, the structs used in the server are not part of the client
ABI. Practically, they are as we copy from the wire straight into the
structs. Changing the struct sizes breaks various wire/server conversions.
Even when the structs have the same size, some internal magic causes
conversions to fail. Visible by diffing the output files of:
setxkbmap -layout de; xkbcomp -xkb :0 busted.xkb
setxkbmap -layout de -print | xkbcomp -xkb - correct.xkb
Interestingly enough, busted.xkb is the working one although the output is
incorrect. Revert the four offending patches until the exact cause of this
breakage can be determined.
This patch restores functionality to Level3 modifiers.