On Mon, Feb 11, 2002 at 03:49:19PM +0100, Maciej W. Rozycki wrote:
> On Mon, 11 Feb 2002, Karsten Merker wrote:
> > > Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that
> > > barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201
> > > keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*".
> > Because the original code does not deliver LK201 keycodes - LK201 keycodes
> > are in the range 0x55 - 0xfb, but the kernel to my knowledge accepts only
> > keycodes in the range 0x01 - 0x7f, so the original code already did a
> > remapping of the LK201 raw codes (it delivered the key numbers from the
> > top left to the downmost right keys, i.e. F1=1, F2=2, F3=3 etc.).
> This may be reasonable for the pc_keyb.c driver, but we don't use it, do
Unfortunately, handle_scancode still uses the 0x80 bit internally
to indicate key up transisitions (see drivers/char/keyboard.c).
So IMHO only keycodes <= 0x7f are usable. Same problem with Access.Bus
LK501 keyboards, btw.
> > This means that the XFree LK201 mapping did not work, and if we have
> > to remap keycodes anyway into the range 0x01-0x7f, using a PC-compatible
> > keymap seemed the best solution to me.
> Then the kernel needs to be fixed -- raw scancodes should be passed as is
> and the translation should be done in kbd_translate(). I'm adding it to
> my to-do list (to be resolved soon, hopefully, together with the annoying
> indefinite timeout when no keyboard is attached).
Hmmm, this change would probably affect a lot of the console
infrastructure. I'm still waiting for the promised rewritten console
code in 2.5 ;-).