Re: [AD] num lock dependent scancode conversion (formerly: nld_readkey())

[George Foot <gfoot@xxxxxxxxxx>]

On Tue, Sep 12, 2000 at 04:12:40PM -0700, stephen.kittelson@xxxxxxxxxx wrote:
> Here are my ideas to fix those problems:
>  1. Before processing the key release, the same conversion takes place.
>  2. Using an array, keep track if a converted key pad scancode has been
> pressed, when a release occurs, only convert if the key pad key being
> released has been recorded to have been pressed as an converted scancode.

I don't think we should mangle the codes used in the key array
at all.  Scancodes refer to specific keys, not the functions of
those keys.  We don't shuffle up the scancodes in order to
support different keyboard layouts, and I don't think we should
process numlock at that stage either.  In any case, it's
relatively trivial to support the numpad arrows through the key
array, using this sort of condition:

    (key[KEY_LEFT] || (key[KEY_4_PAD] && key_shifts & KB_NUMLOCK_FLAG))

As for readkey, the only effect of numlock should be that with
numlock off the ASCII code of numpad keypresses should be set to
the current shift state (as with other non-ASCII keys), and with
numlock on it should be set to the ASCII code of the number key.
I'd suggest that the numpad keys for `/', `*', `-', and `+' and
the numpad Enter key should return their normal ASCII codes if
the shift state is zero.

> even using that test program.

I think the important thing was to try holding a numpad key,
then pressing numlock, then releasing the key -- it should
register the same key as being pressed and released.

George

-- 
Random project update:
09/05/2000: Libnet 0.10.8 uploaded -- a few bugfixes
        http://www.canvaslink.com/libnet/  (try changes-0.10.8.txt)