nanogui: Thread: Scancode kbd driver

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.

From Peter Hartshorn

: 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

Seeing the interest in this product I decided to describe what I have
found of the linux keyboard driver in scan mode.

Key up and key down events are differentiated via the MSB of the
character returned. 1 means key up and 0 means key down. So I do not think
that we can simple map "special" keys (function keys, arrow keys etc) to
128 -> 256. What I was thinking was we have a modifier flag to say this
character is related to a "special" key, and have the application
translate the character to whatever it needs.

For example: I press arrow up, the driver recieves a value of 103, looks
up the table, determines that this is a special character, retrieves the
associated character value from the "special" table, and sets the special
modifier flag to 1. My code then recieves the key event struct, with the
special modifier flag set to 1, it will then convert the character to
whatever it needs for an arrow up. 

Does anyone see a problem with this method? As I feel this will reduce the
impact on coding for the engine and nanox/mwin api.

Peter Hartshorn.