On Tue, 27 May 2003, Maciej W. Rozycki wrote:
> On Tue, 27 May 2003, Geert Uytterhoeven wrote:
> > > Hmm, as I've understood that's a 2.4-only problem as 2.5 has it solved
> > > differently. And I do think the translation really belong to the drivers
> > > that use it -- why can't it be included with the USB keyboard driver or as
> > > a library file? Why an unrelated driver has to be cluttered?
> >
> > It's not really used by a driver, but by the input subsystem itself. You could
> > add the translation to drivers/char/keyboard.c, but then it will break if you
> > use both the input subsystem (e.g. USB keyboard) and some other non-PS/2
> > keyboard driver.
>
> I don't understand -- the scancode mapping is specific to a keyboard
> type. Both PC/AT and USB keyboards may use the same scancodes by chance,
> but others have different ones. So how can the input subsystem need a
> PC/AT specific mapping? Adding the table to drivers/char/keyboard.c
> certainly makes no sense as the file is meant to be generic.
Scancode mapping is indeed specific to the keyboard type.
However, the input subsystem converts Linux input keycodes (cfr.
<linux/input.h>) to PC/AT scancodes, and feeds them to handle_scancode() in
drivers/char/keyboard.c. handle_scancode() calls kbd_translate() to translate
scancodes to keycodes, which is keyboard driver specific.
Since the input subsystem feeds PC/AT scancodes to handle_scancode(),
kbd_translate() needs to know about PC/AT scancodes. For the PS/2 keyboard
driver this is OK, for the dummy keyboard driver this is OK after my patch, but
for any other keyboard driver this will not work.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
