Bug 214453

Using a failsafe xterm session (funny, why doesn't it start xterm -u8?), I can
confirm the problem manifests itself in another way, but is still there. Without
GNOME keyboard magic, pressing shift-altgr-l still doesn't produce any
character, but then, still holding shift and altgr, I can type other characters.
It's less frustrating when nothing beeps at me, but still, it's unusable when
the letters don't appear.

Snooping keypressess with xev, I've found a workaround:
xmodmap -e 'keycode 113 = ISO_Level3_Shift ISO_Level3_Shift'
(which brings me back to my bug 214427 :)). The default for altgr was:
keycode 113 = ISO_Level3_Shift Multi_key
I don't have any idea what the Multi_key is, but I know I don't need it.

As I'm more sure that's a bug in X, not GNOME, here's my relevant xorg.conf portion:
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "pl"

Today I checked on my colleagues' computers at work
- on a fresh install of FC6, the keyboard works as described above (I mean,
doesn't work as it should),
- on FC5, everything works just right.

On FC5, xmodmap -pke shows simply:
keycode 113 = ISO_Level3_Shift
which I was expecting.

With runlevel 3, starting xinit (the xterm, no GNOME) with "us" keyboard gives
me "us" keyboard, as expected. Starting it with my xorg.conf, with "pl"
keyboard, gives me Multi_key on shift-altgr. This is not a GNOME problem, then.

Running with no xorg.conf, but using startx (it loads my GNOME session), Xorg
starts with "us" layout, but GNOME then loads "pl" layout, which is the same. I
even suspect GNOME tells Xorg to use a built-in layout via XKB and there's no
GNOME keyboard layouts at all.

The really strange thing is that if I run:
setxkbmap pl
I get different results from one run to another. One time it maps my Windows
keys to mod4, the other it doesn't. Altgr behavior is always bad.

Try it for yourself. `setxkbmap us` is sufficient to demonstrate the problem
with mod4, but `setxkbmap pl` will show you another problem with
ISO_Level3_Shift. After `setxkbmap pl` run xkbwatch - second column from the
left is mod4, which should turn on if you press one of Windows keys. If it does,
run setxkbmap again, run xkbwatch again and this time it probably won't. Then
see altgr+shift (last and first column) and shift+altgr (the result should be
the same, even with that Multi_key, but sometimes it isn't).

I'll try to restart X without even /etc/X11/Xmodmap existing (in order to not
run xmodmap as a program, maybe it breaks something in XKB? :)).

Well, it doesn't help :) Sometimes my win/mod4 keys work, sometimes they don't
if I run `setxkbmap <layout>`. Funny.

But meanwhile I've nailed down the problem this bug is all about!

/usr/share/X11/xkb/symbols/pl says 'include "level3(ralt_switch)"' and one of
the comments say that "level3(ralt_switch_multikey)" was meant to add Multi_key
to right Alt, while without the "_multikey" suffix it was supposed to work.

In FC5's xorg-x11-xkbdata-1.0.1-7, leve3(ralt_switch) looked like this:
default partial modifier_keys
xkb_symbols "ralt_switch" {
  key <RALT> {
    type[Group1]="ONE_LEVEL",
    symbols[Group1] = [ ISO_Level3_Shift ]
    };
  modifier_map Mod5   { ISO_Level3_Shift };
};
But in FC6's xkeyboard-config-0.8-7, it looks like this:
default partial modifier_keys
xkb_symbols "ralt_switch" {
  // key <RALT> {
    // type[Group1]="ONE_LEVEL",
    // symbols[Group1] = [ ISO_Level3_Shift ]
    // };
  // modifier_map Mod5   { ISO_Level3_Shift };
    key <RALT>  { type[Group1]="TWO_LEVEL",
                  [ ISO_Level3_Shift, Multi_key ]   };
    modifier_map Mod5   { <RALT> };

};

The most drastic discovery is that the damage to Polish users was done not by X
people, but Fedora. SRPM includes xkeyboard-config-0.8-composify-ralt.patch and
that was a fix to bug #193922. I'm going to post my findings there.

I'll try to make this bug a duplicate of bug #193992 and reopen that one,
meanwhile my setxkbmap problems seem to be the real problem behind bug #214427.

According to reporter's wish, this is marked as DUP of 193922

*** This bug has been marked as a duplicate of 193922 ***

BTW, my Super/Mod4 problems from comment #3 were fixed in some of the recent
updates to Xorg.