keyboard scancodes

Andries.Brouwer@cwi.nl
Fri, 10 Dec 1999 17:36:45 +0100 (MET)

It is clear that it is about time to redesign the kernel
keyboard handling, on all levels. The old setup was very
flexible, and was good enough for the past six years or so,
but these days it becomes urgent for the low level handler
to handle keyboards with more than 128 keys and more complicated
escape sequences, and for the keymap level to better handle
UTF-8 and Unicode. We also need a bit more flexibility in
the handling of diacritical signs.

Just to remind myself of the scancode situation on current
PC keyboards, I put some notes together and made them available
at http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html .

For these PC keyboards it seems the proper solution would be
a finite state machine, with tables that can be loaded from
user space, a little bit like setkeycodes does today, but
much more general. The traditional keybaord would then have
three scancode maps (the plain one, one for e0 and one for e1)
and people for whom e0 is not an escape symbol would only
have the plain map, and people for whom also 80 is an escape
symbol would have a fourth map.

I am reasonably well aware of the PC situation. However,
the notes mentioned do not have any information about
Sparc and Apple keybaords, etc. Additions or pointers to
information are welcome.

(And please: everybody with an interesting keyboard: try out
"scancode -s" on the interesting keys, and report.)

Andries - aeb@cwi.nl

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