Bug 5559 - xfree86 maps keys to wrong keycodes when using evdev driver
Summary: xfree86 maps keys to wrong keycodes when using evdev driver
Status: RESOLVED DUPLICATE of bug 7067
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 7.0.0
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-10 11:36 UTC by Ruben Faelens
Modified: 2006-12-28 06:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Ruben Faelens 2006-01-10 11:36:16 UTC
When using the evdev driver, the keycodes/xfree86 file specifies the wrong
keycodes. This results in not being able to use the arrow keys, the
Insert/home/pgup block, and the meta keys. Also, RCTRL and RALT are broken.
I've solved this using an extra alias in keycodes/aliases.

xkb_keycodes "evdev" {
     <RCTL> = 105;
     <RALT> = 108;
     <LWIN> = 133;
     <RWIN> = 134;
     <MENU> = 135;
     <PRSC> = 107;
     <SYRQ> =  107;
     <PAUS> = 127;
     <BRK>  = 127;
     <INS>  = 118;
     <HOME> = 110 ;
     <PGUP> =  112;
     <DELE> = 119;
     <END>  = 115;
     <PGDN> = 117;
     <UP>   =  111;
     <LEFT> = 113;
     <DOWN> = 116;
     <RGHT> = 114;
     <KPDV> = 106;
    <KPEN> = 104;
};

Now, a different keymap can be loaded with
setxkbmap be -keycodes 'xfree86+aliases(azerty)+aliases(evdev)'

Everything is detected correctly when launching X, but when loading any keymap,
the layout is b0rked. I still did not fix the SysRq and Break keys, the kbd
drivers maps different keycodes to them. However, they ARE mapped to the right
keysym when booting into Xorg. Is there some way I can read the current keymap
and keysyms from X?
Comment 1 Sergey V. Udaltsov 2006-01-10 11:45:54 UTC
Ghm.. 
First, would it be possible to fix evdev driver to use the same keycodes as
existing driver? This would be the best way to go...
Also, what do you think would be the most logical way to append these keycodes
into the rules? Honestly, I do not see it there. Setting evdev as a special
model is bad - different keyboard models can use evdev driver. Sure, it is not
layout. May be it is an option - I'm just not sure current engine can process
option->keycode rules..
Comment 2 Ruben Faelens 2006-01-12 02:53:29 UTC
Well, I tested some keys with the evtest utility. Seems that the keycodes evdev
emits are the following:

     <RCTL> = 105;  # keycode X gets when using evdev interface
Event: time 1136994204.710477, type 1 (Key), code 97 (RightCtrl), value 0 #
keycode used by evdev interface
     <RALT> = 108;
Event: time 1136994206.718509, type 1 (Key), code 100 (RightAlt), value 1
     <LWIN> = 133;
Event: time 1136994206.014496, type 1 (Key), code 125 (LeftMeta), value 0
     <RWIN> = 134;
Event: time 1136994204.926481, type 1 (Key), code 126 (RightMeta), value 1
     <MENU> = 135;
Event: time 1136994205.206484, type 1 (Key), code 127 (Compose), value 0
     <PRSC> = 107;
     <SYRQ> =  107;
Event: time 1136994202.454443, type 1 (Key), code 99 (SysRq), value 1
     <PAUS> = 127;
     <BRK>  = 127;
Event: time 1136994202.638445, type 1 (Key), code 119 (Pause), value 1
     <INS>  = 118;
Event: time 1136994201.798432, type 1 (Key), code 110 (Insert), value 1
     <HOME> = 110 ;
Event: time 1136994201.710429, type 1 (Key), code 102 (Home), value 0
     <PGUP> =  112;
Event: time 1136994201.438425, type 1 (Key), code 104 (PageUp), value 1
     <DELE> = 119;
Event: time 1136994201.078419, type 1 (Key), code 111 (Delete), value 0
     <END>  = 115;
Event: time 1136994200.798431, type 1 (Key), code 107 (End), value 1
     <PGDN> = 117;
Event: time 1136994201.270423, type 1 (Key), code 109 (PageDown), value 0
     <UP>   =  111;
Event: time 1136994198.806397, type 1 (Key), code 103 (Up), value 1
     <LEFT> = 113;
Event: time 1136994199.302393, type 1 (Key), code 105 (Left), value 1
     <DOWN> = 116;
Event: time 1136994199.166390, type 1 (Key), code 108 (Down), value 0
     <RGHT> = 114;
Event: time 1136994199.502395, type 1 (Key), code 106 (Right), value 1
     <KPDV> = 106;
Event: time 1136994210.550570, type 1 (Key), code 98 (KPSlash), value 1
    <KPEN> = 104;
Event: time 1136994209.054545, type 1 (Key), code 96 (KPEnter), value 0

So you can see the keycodes emitted by the event interface are different from
the ones X gets by the evdev driver. They aren't the same as the keycodes mapped
in keycodes/xfree86 either. Maybe fixing the evdev driver is the neatest thing
to do. As you can see from the above, keycode translation is allready taking place.

In favor of fixing evdev driver: logical, fixes it where it should be fixed
Contra fixing evdev driver: It adds another translation step in the xkb process.
However, this step seems to be allready happening (see above), so that's not an
issue.


Strange noone noticed this problem before... Maybe I have a bad installation?
Comment 3 Sergey V. Udaltsov 2006-01-12 08:29:18 UTC
I really agree with you. So, redirecting this bug to Input/keyboard...
Comment 4 Ruben Faelens 2006-01-26 21:48:39 UTC
Just for the info: I'm using a Logitech Elite Keyboard.

I: Bus=0003 Vendor=046d Product=c30a Version=1500
N: Name="Logitech Logitech USB Keyboard"
P: Phys=usb-0000:02:02.1-2/input0
H: Handlers=kbd event4 
B: EV=120003 
B: KEY=10000 7 ff800000 7ff febeffdf ffefffff ffffffff fffffffe 
B: LED=1f
Comment 5 Olivier Crête 2006-09-28 14:59:46 UTC
using keycodes/evdev from xkeyboard-config fixed it for me.
Comment 6 parasietje 2006-12-28 06:24:31 UTC

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


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.