[Top] [All Lists]

Re: DECstation keyboard mappings and XFree

To: "Maciej W. Rozycki" <>
Subject: Re: DECstation keyboard mappings and XFree
From: Michael Engel <>
Date: Mon, 11 Feb 2002 16:07:15 +0100
Cc: Karsten Merker <>,
In-reply-to: <>; from on Mon, Feb 11, 2002 at 03:49:19PM +0100
References: <> <>
User-agent: Mutt/1.2.2i

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
> we?

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 ;-).


<Prev in Thread] Current Thread [Next in Thread>