Detecting the used keyboard driver

Peter Hutterer peter.hutterer at
Thu Apr 30 20:09:17 PDT 2009

On Thu, Apr 30, 2009 at 07:20:13PM +0100, Matthew Garrett wrote:
> On Thu, Apr 30, 2009 at 08:09:01PM +0200, Marvin Raaijmakers wrote:
> > Well a scancode is for the kernel like what a X keycode is to the X
> > server, and a kernel keycode is for the kernel what a key symbol is to
> > the X server. So when you change the kernel keycode of a key, then the
> > X server will receive another kernel keycode from the kernel and as a
> > result the key will have another X keycode. So an X keycode is not
> > fixed for a specific key. Furthermore some keys will not have a kernel
> > keycode by default and such keys won't work under X (because the X
> > server doesn't receive anything about these keys from the kernel).
> > Believe me I've thought about this ;)
> For a given kernel keycode and a given X keyboard driver, the X keycode 
> will always be the same. If you're setting the scancode to the canonical 
> kernel keycode that'll be a meaningful transformation. So you could just 
> add those X keycodes to the pc105 keymap, since they're already present 
> in the evdev keymap and so will already produce the correct keysyms with 
> the evdev driver. For example:
> Scancode e007 will be the battery key scancode on a Dell. This will map 
> to kernel keycode 236 (KEY_BATTERY). kbd will read this as e044 and 
> translate it into X keycode 204. evdev will read this as 236 and (I 
> /think/ - I can't remember if the +8 mapping is still relevant for 
> evdev) translate it into X keycode 244.

it is still relevant. The min_keycode 8 is a requirement of the core protocol,
so we just add 8 to all keycodes.

> As long as the kernel keycode is KEY_BATTERY, the X keycode will depend 
> only on whether kbd or evdev is in use. evdev will always use the evdev 
> keymap and that already maps all of the Linux keycodes to appropriate X 
> keysyms. The keymap typically used for the old driver is pc105, and I 
> suspect that it doesn't have these mappings. They'd be easy to add and 
> it's the appropriate place to put them.


More information about the xorg mailing list