Bug#249951: xlibs: KDE keyboard switcher doesn't get along with XKB data in 4.3.0

[Stefan Baums <baums@u.washington.edu>]

[I resend this email because the bug had temporarily been assigned
to a wrong, non‐existing package, so people probably did not
receive it.]

I am not an expert in XKB configuration, but will do my best to
help pin down this bug.  Please let me know of any specific things
to test out on my system.  But I also feel that this bug should be
easy to reproduce on other people’s computers.

> Sounds like the Russian layout has messed up either the key
> mapping or the modifier mapping of the Alt key.

I’m not sure what the former means, but do not believe that it is
the latter.  Under the “us” keyboard layout, Xev says the
following when I press Alt + f:

    KeyPress event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1303203, (134,153), root:(136,155),
        state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
        XLookupString gives 0 bytes:  ""

    KeyPress event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1303589, (134,153), root:(136,155),
        state 0x8, keycode 41 (keysym 0x66, f), same_screen YES,
        XLookupString gives 1 bytes:  "f"

    KeyRelease event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1303813, (134,153), root:(136,155),
        state 0x8, keycode 41 (keysym 0x66, f), same_screen YES,
        XLookupString gives 1 bytes:  "f"

    KeyRelease event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1303853, (134,153), root:(136,155),
        state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
        XLookupString gives 0 bytes:  ""

After switching to the “ru” keyboard layout (variant “phonetic”),
I get the following:

    KeyPress event, serial 16, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1330305, (121,143), root:(123,145),
        state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
        XLookupString gives 0 bytes:  ""

    KeyPress event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1330533, (121,143), root:(123,145),
        state 0x8, keycode 41 (keysym 0x6c6, Cyrillic_ef), same_screen YES,
        XLookupString gives 2 bytes:  "ф"

    KeyRelease event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1330742, (121,143), root:(123,145),
        state 0x8, keycode 41 (keysym 0x6c6, Cyrillic_ef), same_screen YES,
        XLookupString gives 2 bytes:  "ф"

    KeyRelease event, serial 21, synthetic NO, window 0xa00001,
        root 0x3f, subw 0x0, time 1330756, (121,143), root:(123,145),
        state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
        XLookupString gives 0 bytes:  ""

The output for pressing and releasing the ALt key under the two
layouts looks identical in all relevant respects.  The output for
the f key differs, not unexpectedly, in keysym (0x66, f vs. 0x6c6,
Cyrillic_ef) but not in keycode (41).

I performed this test under KDM’s session type “Failsafe” (a bare
Xterm without window manager) to rule out any influence from KDE &
Co.  The symptoms are exactly the same as under KDE: with the
Russian layout I could not, for instance, use Alt + f to open the
File menu in Gedit.

> I am downgrading it to normal because bugs like this only seem
> to affect people using tools like the GNOME and KDE keyboard
> switchers.

That is not correct, the problem lies deeper.  I get exactly the
same misbehaviour when I switch to the Russian keyboard layout
from the command line using

   setxkbmap -layout ru -variant phonetic

(as I did in the above Xev test).  I don’t know if that makes the
bug serious enough to bump up it’s severity to “important” again,
but it sure is annoying, and I would imagine it affects a fair
number of Debian users.  At the very least, I suggest changing the
bug title to reflect the more general nature of the bug.  (Sorry,
I don’t know how to do so myself, and it’s probably the package
maintainer’s prerogative to do so anyway.)

Let me also point out that my system runs under an en_US.UTF-8
locale, which may or may not be relevant.  I do not know how to
test whether it is: Entering Russian under an en_US.ISO-8859-1
locale is of course not even meant to be possible, and when I
start under a Russian 8‐bit locale such as ru_RU.KOI8-R, the menus
in e.g. Gedit have completely different, Russian names with
correspondingly different, Russian shortcuts.

Stefan

-- 
Stefan Baums
Asian Languages and Literature
University of Washington