Bug 476358 - german keyboard layout not working correctly (i.e. 'Pipe' Symbol and cursor keys)
german keyboard layout not working correctly (i.e. 'Pipe' Symbol and cursor k...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-13 09:07 EST by Harald
Modified: 2009-01-14 18:37 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-14 18:37:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
install log of F10 (48.13 KB, text/plain)
2008-12-13 09:07 EST, Harald
no flags Details
Xorg.log (22.24 KB, text/plain)
2008-12-13 09:08 EST, Harald
no flags Details
Xev output for several keys like "AltGr" "Backspace" and "Cursor Up" which did not work in a terminal window. (18.29 KB, text/plain)
2008-12-21 12:19 EST, Thomas Hartwig
no flags Details
xorg.conf from physical box running F9 (5.67 KB, text/plain)
2009-01-09 15:00 EST, Harald
no flags Details
Xorg.log from physical box running F9 (59.00 KB, text/plain)
2009-01-13 13:30 EST, Harald
no flags Details

  None (edit)
Description Harald 2008-12-13 09:07:15 EST
Created attachment 326818 [details]
install log of F10

Description of problem:
I installed F10 in VMWare, and used the german keyboard layout. Most things seem to be working well, all characters are available as should be, except for '|' and the cursor keys.

Version-Release number of selected component (if applicable):
# rpm -qa | grep evdev
xorg-x11-drv-evdev-2.0.7-3.fc10.x86_64

How reproducible:
Always when using German keyboard layout in Gnome terminal.


Steps to Reproduce:
1. install F10 with Gnome desktop, use german kbd layout (PC-105) with no-dead-keys
2. log in to Gnome desktop and start a terminal 
3. try to use the cursor-up-key (to recall the last command from history in bash)
4. try to enter the pipe '|' symbol, i.e. in a command as rpm -qa | grep evdev (to enter '|' on german layout you have to press the right <ALT> key, just right of <SPACE>, together with the key just right of the left <SHIFT> key)
  
Actual results:
cursor-up results in screen print, '|' seems to cause a <Enter> in the terminal, but already using the right <ALT> key


Expected results:
cursor-up should (using bash) recall the last command, a pipe symbol should be possible to enter.


Additional info:
Please see also bug #365711 where something similar had been reported by myself for F7, but F9 was doing fine. Now F10 has again some flaws.

With F7 evdev i could fix the issue with the pipe by changing the following files:

in /usr/share/X11/xkb/keycodes/evdev i added the following line:
<LESS> = 94;

in /usr/share/X11/xkb/symbols/de i added this line:
key <LESS>  { [      less,    greater,           bar,   brokenbar ] };



In /usr/share/X11/xkb/keycodes/evdev i found <LSGT> = 94 and in in /usr/share/X11/xkb/symbols/de i found these entries:
key <LSGT> { [  less, greater, 	guillemotleft, guillemotright	] }
key <LSGT> { [ adiaeresis, Adiaeresis, bar ] };

i am going to add the xorg.log and the install.log.
Comment 1 Harald 2008-12-13 09:08:02 EST
Created attachment 326819 [details]
Xorg.log
Comment 2 Peter Hutterer 2008-12-17 19:55:20 EST
Please attach the output of xev after hitting the keys that don't work.

In your xorg.conf, try setting Option "AutoAddDevices" "off" in the ServerLayout. If you don't have an xorg.conf, just add a Section "ServerFlags" with the above line.

What's your host system?
Comment 3 Thomas Hartwig 2008-12-21 12:17:49 EST
Hello Peter,

"AutoAddDevices" "off" works like charm and did resolve the problem for me. This was only happen in my KDE konsole window. So this might be related to terminal sessions only. I will attach an xev output to this bug. Pressed following keys always multiple times there "AltGr" "Backpsace" "Cursor Up".

Thanks
Thomas

PS: If you need further information to resolve this, let me know.

Linux version 2.6.27.7-134.fc10.i686.PAE (mockbuild@x86-4.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Mon Dec 1 22:30:53 EST 2008
Comment 4 Thomas Hartwig 2008-12-21 12:19:28 EST
Created attachment 327584 [details]
Xev output for several keys like "AltGr" "Backspace" and "Cursor Up" which did not work in a terminal window.
Comment 5 Peter Hutterer 2008-12-21 21:59:15 EST
AFAIK this is an vmware issue. Somewhere in vmware (qemu does the same) the keyboard mapping is off - it translates from evdev scancodes (which are defined in linux/input.h) to AT scancodes. This is what you see here, the keycode 111 (Up in evdev) is PrintScreen.

See also: Bug 463765
Comment 6 Thomas Hartwig 2008-12-26 04:38:49 EST
Please note that I had this error in no virtual machine environment. I have a standard i386 Fedora installation on a laptop.
Comment 7 Harald 2009-01-05 07:07:04 EST
Sorry for my late answer, but i was offline for some time.

Rgd the issue, i tried creating the xorg.conf, but with no luck, it didn't change anything on the keys not working. I also realized that the same happens on the console of the virtual machine, so i agree it will not be related to the evdev driver. The main difference is that it changed the keyboard layout to US and no longer DE. Also the 'VMWare Tools' are no longer active.

My host machine is a F9 (running 2.6.27.9-73.fc9.x86_64), with VMware workstation (6.5 VMware-Workstation-6.5.1-126130.x86_64). The VM is running F10 with 2.6.27.7-134.fc10.x86_64.

But to the keys not working, i.e. the right Meta-Key (labeled Alt-Gr) acting like <Enter>, also the cursor up key acts like 'print-screen'. Please note that the xev output is generated with AutoAddDevices Off being active.


========================================
Output of xev from the VM:

right Meta key:
KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x5d, subw 0x0, time 853026, (235,-2), root:(238,46),
    state 0x10, keycode 108 (keysym 0xff8d, KP_Enter), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x5d, subw 0x0, time 853091, (235,-2), root:(238,46),
    state 0x10, keycode 108 (keysym 0xff8d, KP_Enter), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False


cursor up:
FocusOut event, serial 27, synthetic NO, window 0x3c00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 27, synthetic NO, window 0x3c00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 27, synthetic NO, window 0x0,
    keys:  31  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

FocusOut event, serial 27, synthetic NO, window 0x3c00001,
    mode NotifyNormal, detail NotifyNonlinear

PropertyNotify event, serial 27, synthetic NO, window 0x3c00001,
    atom 0x11f (_NET_WM_ICON_GEOMETRY), time 971721, state PropertyNewValue


at this point the gnome screenshot dialog appears
========================================

xev output on the host machine:

right Meta key:
KeyPress event, serial 30, synthetic NO, window 0x3e00001,
    root 0x7b, subw 0x0, time 6877973, (667,500), root:(671,549),
    state 0x10, 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

KeyRelease event, serial 30, synthetic NO, window 0x3e00001,
    root 0x7b, subw 0x0, time 6878039, (667,500), root:(671,549),
    state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

cursor up:
KeyPress event, serial 30, synthetic NO, window 0x3e00001,
    root 0x7b, subw 0x0, time 7051060, (852,802), root:(856,851),
    state 0x10, keycode 111 (keysym 0xff52, Up), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3e00001,
    root 0x7b, subw 0x0, time 7051116, (852,802), root:(856,851),
    state 0x10, keycode 111 (keysym 0xff52, Up), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

===========================================

From what i am able to see, the keycode for the rigth Meta key is on both machines 108, which indicates some other trouble then a keytranslation of VMWare?
Comment 8 Peter Hutterer 2009-01-05 17:19:15 EST
the simple reason here is the abstractions of keycodes in X. keycodes are mapped to keysyms (i.e. the symbols you want like 'a', 'enter', etc.). F9 and F10 have different keyboard drivers ('kbd' vs. 'evdev') and the keycodes are different.

Hence what is the keycode for the up key in F10 is the keycode for the PrtScr key in F9. I guess what VMWare does is to simply forward the keycode to the client machine as-is. It forwards the kbd keycodes, so you need to ensure that the client uses the same mapping.

Try the following command on the client machine:
setxkbmap -rules base -layout de -model pc105

That should force the same keycode table as F9 has. Except that I don't know how to get that into persistent configuration, other than the AutoAddDevices "false" option. As soon as the evdev driver loads up, it forces the "evdev" ruleset and anything after that will be messed up.
Comment 9 Harald 2009-01-06 05:26:58 EST
I tried the command, but although it changed the keyboard layout to german, it has not changed the behavior of the right meta key or the cursor up key.

Right Meta still results in Enter and cursor up still in the screenshot dialog.

With F8 i used the evdev driver as i had a multi seat configuration running, but with F9 i already noted that this is no longer possible. How can i determine which keyboard drive is active on F9?

I also tried some variation, as i compared the command with my old keyboard definition in F8:

setxkbmap -rules xorg -layout de -model evdev

Now my right meta key works as expected and i can enter the pipe symbol, still the cursor up key results in the screenshot dialog. I am just focussing on those two keys as they are the most striking ones, but the insert and delete, key are not working correctly too, while home and end key are working as expected.

I also attached the xev output of the right meta key from the VM after entering the changed setxkbmap command.

KeyPress event, serial 27, synthetic NO, window 0x1400001,
    root 0x5d, subw 0x0, time 993596, (-391,365), root:(415,476),
    state 0x10, 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

KeyRelease event, serial 30, synthetic NO, window 0x1400001,
    root 0x5d, subw 0x0, time 993663, (-391,365), root:(415,476),
    state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

At last i also tried the print key in the VM, which should normally result in the screenshot dialog (but does not actually) with xev:

KeyPress event, serial 30, synthetic NO, window 0x2e00001,
    root 0x5d, subw 0x0, time 1521074, (41,-15), root:(847,96),
    state 0x10, keycode 107 (keysym 0xff61, Print), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x2e00001,
    root 0x5d, subw 0x0, time 1521140, (41,-15), root:(847,96),
    state 0x10, keycode 107 (keysym 0xff61, Print), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 10 Peter Hutterer 2009-01-06 18:49:28 EST
The problem with the printscreen is that metacity puts a grab on the keycode but doesn't update it when the keymap changes. That's why it still comes up with the dialog. Restarting metacity will fix that.
Comment 11 Harald 2009-01-07 08:19:10 EST
Restarting metacity did it. The screenshot works as it should as well as cursor keys.

The only keys not working are Insert and Delete, but i am unable to even get an event in xev when pressing those keys. I guess this is related to VMware itself not passing that events to the VM.

This only leaves me with the question how to keep this setting during a restart? Shall i simply add two lines in the common user profile (etc/profile)? I tried to edit the xorg.conf with information on the keyboard, but nothing changed.
Comment 12 Peter Hutterer 2009-01-08 00:02:30 EST
btw. did you set AutoAddDevices "off" in the F9 or the F10 box? I should be set in the F10 box.
Comment 13 Harald 2009-01-08 10:23:05 EST
i set the AutoAddDevice Off in the F10 Box (the VM)
Comment 14 Peter Hutterer 2009-01-08 19:33:06 EST
I'm getting really confused now. Just checked your logs again:

(In reply to comment #7)
> Output of xev from the VM:
> 
> right Meta key:
> KeyPress event, serial 30, synthetic NO, window 0x3c00001,
>     root 0x5d, subw 0x0, time 853026, (235,-2), root:(238,46),
>     state 0x10, keycode 108 (keysym 0xff8d, KP_Enter), same_screen YES,
> "   XLookupString gives 1 bytes: (0d) "
> "   XmbLookupString gives 1 bytes: (0d) "
>     XFilterEvent returns: False

108 for KPEN is the xfree86 model.
 
> xev output on the host machine:
> 
> right Meta key:
> KeyPress event, serial 30, synthetic NO, window 0x3e00001,
>     root 0x7b, subw 0x0, time 6877973, (667,500), root:(671,549),
>     state 0x10, 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

108 for RALT is the evdev model keys. If this box is the F9 box, this shouldn't happen as we disable evdev in F9 (unless you have some custom per-keyboard setup in the xorg.conf).

what am I missing here?
Comment 15 Harald 2009-01-09 15:00:37 EST
Created attachment 328583 [details]
xorg.conf from physical box running F9
Comment 16 Harald 2009-01-09 15:01:58 EST
I was runnning a mult seat config on the physical box with F8. To be able to do so i had to change the keyboard configuration to use evdev instead of the normal keyboard driver in X (which always uses all keyboards for input). 

I then updated the box to F9, which left the multi seat non-functional and i have found no way to reenable it. F9 does not use the X server configs from the xorg.conf anymore, but all keyboard configs in there still have the evdev driver. 

So i guess there is a good chance that my keyboards in F9 are using the evdev driver, though the X Server is not started with any of the server layouts there. I just added to xorg.conf from the physical box (F9) to let you inspect it yourself for clarification.
Comment 17 Peter Hutterer 2009-01-11 17:38:32 EST
oh, well that explains a lot. can you please attach the xorg.log from the F9 server too so I can have a look at what keyboard is actually active.


Replace "Option XkbRules" "xorg"" in the Keyboard1 section with evdev instead of xorg. That should just do the trick.

Or just remove the reference to Keyboard1 in the ServerLayouts, that way F9 picks up the kbd driver and the AutoAddDevices off trick in the F10 boxk works.
Comment 18 Harald 2009-01-13 13:30:59 EST
Created attachment 328900 [details]
Xorg.log from physical box running F9
Comment 19 Harald 2009-01-13 13:46:52 EST
ok, i removed (commented out) all references to the keyboards in the xorg.conf for the F9 box. 

When i am now starting the VM with F10, the keyboard is working in US layout - qwerty - (AutoAddDevices Off is still set). But all special keys are working, even Insert and Delete. I am not sure if this was to be expected.
Comment 20 Peter Hutterer 2009-01-13 21:04:53 EST
just put a normal keyboard section in, driver kbd and the layout options you want. Then AutoAddDevices off in the F10 box and it should work.
Comment 21 Harald 2009-01-14 16:31:39 EST
there seems to be a little missunderstanding, the keyboard on the F9 (physical box) is working correctly and was always working correctly (german keyboard layout, all special keys as expected).

Just after the last change in the F9 xorg.conf (removing the references to keyboards from the server layouts), the keyboard in the F10 box (VM) is now working with US layout. I tried adding a keyboard section in the xorg.conf of the F10 box without success.

But in the administration menu i could see that the config had forgotten about the german layout. After adding that again everything is ok now. It kept working after i deleted (renamed) the xorg.conf on the F10 and restarted.

Seems to have been a side effect of the evdev driver in the physical box. As your support and hints.
Comment 22 Harald 2009-01-14 16:34:03 EST
My last sentence should have been:

As multiseat is not working with F9 anyway this is fine for me. Thank you for your support and hints.
Comment 23 Peter Hutterer 2009-01-14 18:37:48 EST
Ok, I'm closing this bug as a CANTFIX for the following reason:

F9 and F10 have different keycodes (due to the kbd/evdev driver change) and they can cause confusion.
The workaround is to add Option "AutoAddDevices" "off" to the server as this forces the server to use kbd instead of evdev. Once all machines use kbd, the keycode mixup is gone (in theory you could also force F9 to use evdev, but we have a patch in the server to prevent that)

This workaround is the only solution so far.

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