Bug 214453 - can't enter 4th level character if shift is pressed first
can't enter 4th level character if shift is pressed first
Status: CLOSED DUPLICATE of bug 193922
Product: Fedora
Classification: Fedora
Component: xorg-x11-xkbdata (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Depends On: 214427
  Show dependency treegraph
Reported: 2006-11-07 13:08 EST by Leszek Matok
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-09 10:00:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Leszek Matok 2006-11-07 13:08:45 EST
Description of problem:
I guess it's called the 4th level character, but let me make it more clear:
- pressing "l" gives me "l"
- pressing shift+"l" gives me "L"
- pressing altgr+"l" gives me "ł" (this is 3rd level, I guess)
- pressing altgr+shift+"l" gives me "Ł" (this is the 4th?)
- pressing shift+altgr+"l" gives nothing, and the next key pressed makes my pc
speaker emit a beep.
In FC5 and earlier, shift-altgr worked just like altgr-shift, which is what I
want. Now it doesn't serve any obvious purpose (probably it's meant to denote
start of some special sequence, but I haven't discovered any), instead making it
impossible to input a word in CAPS or type in '"Ł"' - my fingers are optimizing
this as shift + ( ', altgr+l, ' ), but now I need to type: shift + ', let go
shift, altgr + shift + l, let go altgr, '. Can you imagine how furious I am
turning when trying to type anything with Polish capitals? This should have a
critical priority! :)

Version-Release number of selected component (if applicable):
Updated FC6
Polish "programmers" keyboard layout, simply "Poland" in GNOME.

The component selection is almost random. I even suspect it's rather something
in GNOME than in Xorg itself, but who knows? I can't nail down the problem
because keyboard handling in X is a totally new land for me. That's why I don't
know which component to select in the first place. If that one's wrong, please
help me select an appropriate one.

How reproducible:

Steps to Reproduce:
1. Press altgr-shift-[acelnoxz], proper character appears.
2. Press shift-altgr-(same key), things break.
Comment 1 Leszek Matok 2006-11-07 14:00:22 EST
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"
Comment 2 Leszek Matok 2006-11-08 12:01:06 EST
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.
Comment 3 Leszek Matok 2006-11-08 13:44:26 EST
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? :)).
Comment 4 Leszek Matok 2006-11-08 14:20:35 EST
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> {
    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.
Comment 5 Matěj Cepl 2006-11-09 10:00:01 EST
According to reporter's wish, this is marked as DUP of 193922

*** This bug has been marked as a duplicate of 193922 ***
Comment 6 Leszek Matok 2007-02-11 03:29:36 EST
BTW, my Super/Mod4 problems from comment #3 were fixed in some of the recent
updates to Xorg.

Note You need to log in before you can comment on or make changes to this bug.