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 +
