Messages in this thread | | | Date | Fri, 10 Dec 1999 17:36:45 +0100 (MET) | From | Andries.Brouwer@cwi ... | Subject | keyboard scancodes |
| |
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/
| |