Re: Change in keycodes generated by the keyboard

[Giuseppe Bilotta <bilotta78@hotpop.com>]

On Tue, 20 Sep 2005 14:37:13 +0200,
jj.iglesias@intranet.cajabadajoz.es wrote:

> Hi all!
> 
> I've got a Microsoft Wireless Natural Multimedia keyboard (it was a
> gift...) and I've been using its "extra" keys upto the 2.6.9 (maybe 2.6.10,
> I'm not sure!) version of the kernel. I use to update the kernel as
> frequently as I can and one day I noticed that these extra keys didn't work
> any more.
> 
> When I was given the keyboard I started to make it work under my linux, and
> thus I used tools such as "showkey" and I learnt the differences between
> scancodes, keycodes or at least I tried to learn them.
> 
> Well, I've found that the last revisions of the 2.6 kernel have changed the
> keycodes generated by the keyboard. There are "short" keycodes such as
> 0x1a, "extended normal" keycodes such as "0x008102" (I'm writing at my
> work, trying to remember the structure of the keycode, but the point is in
> the "81"); and "extended anormal" keycodes that are similar to the previous
> but they include "82".
> 
> These last keycodes are not sensed by any application, mainly X. I remember
> that previous revisions of the 2.6 kernel had sixteen places empty in
> certain array used to convert from keycodes to scancodes. The kernel, then,
> complainted saying that "keycode 240 has no scancode" or something... I
> filled the array with scancodes that weren't in use and the extra keys
> begun to work.
> 
> But now (that array continues having sixteen empty spaces) the keycodes
> generated by the keyboard are completely different.
> 
> Any help? Any capture that I could do and email it?

>From version 2.4 to version 2.6 the kernel input system underwent a
total rewrite. One of the side effects of this has been that programs
are not able to read the input devices in raw mode. Rather, the kernel
has a few internal tables that translate from the keycodes to a
specific *emulated* set of "raw mode" scancodes.

For unassigned keys, you can do (from the console)

setkeycodes <unhandled scancode> <assigned keycode>

to assign a particular keycode to a particular (unhandled) scancode,
and this *will* make the key recognized outside of the kernel too
(e.g. in X).

HOWEVER, at least for PS/2 keyboards (I don't have an USB keyboard and
don't know what kind of keyboard is yours) the raw scan code reported
to programs like X will *not* be the actual key scancode (i.e. the one
you fill up in <unhandled scancode> above). Which I think is a bug in
the new input system.

I have a problem similar to yours: I have a Dell laptop (Inspiron
8200) with 7 multimedia keys; three of these (volume up/down/mute) are
correctly recognized by the kernel and correctly passed over to other
apps (in particular the X server), the other four are unhandled (0x81
to 0x84).

The X keymaps include support for the Dell Inspiron keys (by means of
inet(inspiron)), and this works perfectly when using a 2.4 kernel. The
volume keys still work with the 2.6.

To make the other four keys work "correctly" (with the same map) I had
to manually search through all the keycodes until I found those that
got backtranslated to the "correct" scancodes for X. (My final finding
was that I had to map e001 to 171, e002 to 172, e003 to 187 and e004
189).

If you look at some past messages on the topic (search e.g. for
Inspiron 8200) you'll see that this was already discussed.

However, I just noticed that the atkbd module has a (don't know how
recent) option "softraw". I'm not sure what it does exactly, though.

-- 
Giuseppe "Oblomov" Bilotta

"I'm never quite so stupid
 as when I'm being smart" --Linus van Pelt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/