On Fri, 23 May 2003, Maciej W. Rozycki wrote:
> On Fri, 23 May 2003, Geert Uytterhoeven wrote:
> > This patch fixes the arrow keys (and all other keys that generate E0/E1
> > scancode prefixes on AT keyboards) by adding support for E0/E1 scancode
> > prefixes to the dummy keyboard driver if CONFIG_INPUT=y.
> >
> > Rationale: When using the new input layer (i.e. with a USB keyboard or a custom
> > input device), the input layer relies on kbd_translate() in the low-level
> > keyboard driver to convert from AT-style scancodes to keycodes. If you don't
> > have a PS/2 keyboard interface and don't compile in the PS/2 keyboard driver,
> > you have to enable the dummy keyboard driver, which naively assumes that
> > keycodes and scancodes are interchangeable. This is correct if you do not have
> > a keyboard, but fails for prefixed scancodes if you do have a keyboard which
> > uses the new input layer.
>
> Hmm, if the PC/AT keyboard translation is needed by other devices beside
> pc_keyb.c, then why isn't the common part put into a separate file to be
> used by all devices depending on this translation as needed? I think
> dummy_keyb.c should be kept plain and simple as it is now.
In 2.5.x it's (probably) that way. In 2.4.x the input layer is more like a hack
to get USB working. On PCs, you always compile in both PS/2 keyboard and USB
keyboard support, so it always works. The dummy_keyb.c is used on MIPS only.
BTW, I forgot to mention: I just copied what the PPC guys do on PowerMac, cfr.
drivers/macintosh/mac_hid.c.
But it indeed makes sense to move kbd_translate() into the input layer itself.
Vojtech, what do you think?
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
