linux-mips
[Top] [All Lists]

Re: [PATCH] Arrow keys on USB keyboards

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] Arrow keys on USB keyboards
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 27 May 2003 16:16:22 +0200 (MET DST)
Cc: Ralf Baechle <ralf@linux-mips.org>, Linux/MIPS Development <linux-mips@linux-mips.org>
In-reply-to: <Pine.GSO.4.21.0305271552430.29405-100000@vervain.sonytel.be>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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        +


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