nanogui@linuxhacker.org

Hello,

A few days ago I ran into a problem using Microwindows on an Accelent Systems xscale
reference platform running Accelinux and after a bit of hacking, I've come up with the
following analysis:


The TTY_Read function in kbd_ttyscan.c reads a byte from /dev/tty and filters out the
pressed/released bit to generate a scancode.  Then it looks up that scancode in a keymap
array to get to associated key.  It uses that key to see if the user hit one of the
modifier keys (ALT, SHIFT, CTRL, etc.) or F1 through F12 in combination with ALT (to
change consoles).  If the key was not one of those, then it translates the key using
the keymap that it loaded out of the kernel at startup.

This approach is fine, assuming that the scancodes for the modifier and function keys
are the same for all keyboards.  I suspect that for most keyboards, this is true, however
the Accelent keyboard generates different scancodes for the modifier and function keys
than the average keyboard, and some of the alphanumeric keys generate scancodes that
would generally be generated by modifier or function keys.

I modified TTY_Read() to immediately call TranslateScancode() after stripping off the
pressed/released bit and comment out the entire if/else/endif block that it was originally
called in.  It seems to work for the limited set of keys that my application cares about,
but I'm not sure how robust it is.  Specifically, I see a switch statement further down
in the code that evaluates the scancode directly instead of the character that it mapped
to.  I can imagine that on my platform it is often modifying the scancode for the wrong
key.

At any rate, I thought I should post this to the group.  I'd appreciate any feedback
that anyone can contribute as well.  Hopefully it will lead to a permanent fix for the
Accelent reference platform.

Dave Muse
dmuse@4accesscommunications.com