Game keys

[Mitch Bradley]

David Lang wrote:
> ideally I want to figure out how to get these keys into the kernel, at 
> that point any userspace can deal with them.

The game keys produce scancodes that are folded into the keyboard data 
stream.  The kernel sees them interspersed with ordinary keyboard scan 
codes.  What it does with them depends on a lot of factors that I 
haven't bothered to understand in detail.  I think there are several 
different ways that scancodes can be mapped into ASCII or other events, 
depending on whether you are using a console or X or whatever.  I 
respectfully submit that getting the codes from the kernel to "any 
userspace" is quite a bit more complicated in practice than the above 
assertion seems to imply.

Here is an OFW recipe you can use to see the scancode sequences:

ok disable-interrupts
ok stdin @ iselect
ok  20 0 do  begin get-data? until .  loop

they type some keys or press some game buttons.

That will display 32 (0x20) scancodes.  You can re-execute it (up-arrow, 
enter) to see more.

OFW uses "scan set 1", so the codes that you will see are from that 
set.  It turns out that the game keys codes are always from scan set 1; 
they don't change if you tell the keyboard to use scan set 2, and they 
don't change if you tell the EC to translate or not translate from set 2 
to set 1.

The general form of scanset 1 is:

[ optional 0xe0 prefix ]  make-code
[ optional 0xe0 prefix ]  break-code

For a given key, break-code is 0x80 | make-code

The 0xe0 prefix is generally used to distinguish between multiple copies 
of the "same" key.  For example, a full sized keyboard has two "1" keys, 
one in the row above the alpha keys and one in the numeric keypad.  If 
you try the above program with the game keys, you will see that the left 
and right game key clusters use the same base codes, but the right 
cluster has prefixes.

It's also possible to ask the embedded controller to tell you which game 
keys are currently depressed; the return value is a bitmask of which 
ones are down.  That's useful for early firmware tests before the 
keyboard event stream is initialized, but not particularly useful in the 
Linux event-driven regime.