On Tue, 27 May 2003, Geert Uytterhoeven wrote:
> 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.
Oh what a mess! -- why does it do so? Since as I understand these input
keycodes are already translated from scancodes, why do they need to be
translated "back" to PC/AT scancodes (possibly with private inventions for
keys that do not exist on PC/AT or PS/2 keyboards) only to be translated
to medium-raw keycodes (for a total number of four translations from an
original scancode to a final cooked sequence)? Why can't the input layer
provide its own kbd_translate() function translating directly from input
keycodes to medium-raw keycodes (or why the input keycodes are different
from medium-raw keycodes at all)?
After all it looks like the input layer can be treated like a virtual
keyboard driver itself.
> 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.
Why can't the input layer be fixed instead? Given the interface between
the input layer and drivers/char/keyboard.c is internal the impact on
backend drivers should be nonexistent, hence no incompatibility problem
for 2.4.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|