Bug 19602 - ALT-GR switch on german keyboard layout behaves weird
Summary: ALT-GR switch on german keyboard layout behaves weird
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 19401 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-16 02:18 UTC by Markus Heier
Modified: 2009-07-09 18:48 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
10-x11-input.fdi hal keyboard configuration (1.99 KB, text/plain)
2009-01-16 02:18 UTC, Markus Heier
no flags Details
Xorg.log (19.39 KB, text/plain)
2009-01-16 02:41 UTC, Markus Heier
no flags Details

Description Markus Heier 2009-01-16 02:18:49 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.
Comment 1 Markus Heier 2009-01-16 02:41:54 UTC
Created attachment 22027 [details]
Xorg.log

Attached my Xorg.log
Comment 2 Peter Hutterer 2009-01-16 02:57:25 UTC
do you see the same problem when running setxkbmap -layout de -variant nodeadkeys? At least that command seems to work fine here.
Comment 3 Markus Heier 2009-01-16 03:36:15 UTC
(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.
Comment 4 Peter Hutterer 2009-01-17 13:33:08 UTC
*** Bug 19401 has been marked as a duplicate of this bug. ***
Comment 5 Peter Hutterer 2009-01-17 13:33:50 UTC
This isn't really fixed, we still need to figure out why the settings don't get taken. Reopening.
Comment 6 Conrad Kostecki 2009-01-17 13:40:24 UTC
If you need some help, let me know, how i could help with this problem :)
Comment 7 Peter Hutterer 2009-01-17 18:05:02 UTC
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).
Comment 8 Peter Hutterer 2009-02-12 22:02:36 UTC
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?
Comment 9 Peter Hutterer 2009-07-08 23:36:29 UTC
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.
Comment 10 Peter Hutterer 2009-07-09 00:34:16 UTC
bisected to 61c508fa78aa08ea2666fde950fbafad95d65056.

Author:     Daniel Stone <daniel@fooishbar.org>
AuthorDate: Fri Apr 25 19:47:16 2008 +0300

    XKB: Sanitise vmods in actions

    Turn vmods from two unsigned chars into one int.
Comment 11 Peter Hutterer 2009-07-09 18:48:12 UTC
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.

commit 3711d68f657c77b947cc4670cc4eac4f62de3af8.
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.