nanogui: Scancode kbd driver
Subject:
Re: Scancode kbd driver
From:
"Greg Haerr" ####@####.####
Date:
8 Nov 2000 22:09:36 -0000
Message-Id: <035a01c049d0$c4e5e5c0$15320cd0@gregh>
: If anyone is interested I have started work on a scancode driver for
: linux. Currently it can translate the qwerty keyboard to ascii. And
: mappings can be created via an include file at compile time. When this
: gets a bit more complete, I will mail it here.
I am very interested in this. I just started work on redesigned keyboard
handling for Nano-X, but haven't written any code, just thinking about
how it ought to work.
Basically, my thoughts are that an application might want to select
for either "cooked" or "raw" (scancode) keystrokes, or both. Basic
applications will select cooked mode and use the final key values
supplied in a KEY_CHAR message. Key values less than 256
should probably be in ascii, latin-1, or oem code page, while values
> 256 could be indicative of parsed special key values, like F1 etc.
Under X, parsing keys like F1 is simple, while under Linux
console, it's a bit trickier, and may not be directly supported.
If the application selects for raw mode reporting, then it [also]
gets separate keypress and keyrelease events, which report the
corresponding scancodes only. The Nano-X server keeps track of
a separate, say 256 element array which keeps track of the
shift/ctrl/alt state of the entire keyboard, and deals with turning
series of scandown/scanup sequences into "characters." Also, the
application may request the state of this table in whole, for it's
own use.
Finally, the GetScreenInfo function probably needs to return info
about whether or not the linked-in kbd driver can support cooked
and/or raw modes, so that the application knows whether it will
receive these events or not. The kbd driver probably needs to
function in it's maximally-useful state, ie. if it can support scancodes,
then the driver always runs in scancode mode, with conversions
done with tables. If the driver doesn't support scancodes, then
it operates in cooked mode only. This eliminates the business of
switching modes during operation.
Regards,
Greg
