david at lang.hm
david at lang.hm
Mon Nov 3 03:07:30 EST 2008
On Sun, 2 Nov 2008, Mitch Bradley wrote:
> 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.
let me try again.
I want to find out what the scancodes are, so that I can then document how
to get them mapped to keystokes via some mechanism similar to the kernel
keymaps (for console stuff) and xkb (for X stuff). the idea being that
once these are mapped to be keystrokes, exactly what keystrokes they are
mapped to can be tweaked, and things can be configured to take action on
the current situation seems to be that the scancodes don't map to
anything, the OLPC Sugar build is grabbing and processing the raw
scancodes and taking action on them.
having a config file for the kernel or X to make use of the keys doesn't
bother me, requireing a specific desktop to make use of the keys does.
> 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.
how do these codes map to what I read about for dumpkeys/loadkeys
(console) or xkb map files (for X)?
> 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.
this can be extremely useful for games (no worry about events getting
buffered, you can find out exactly what the status is _now_), but it's not
what I'm looking for.
I'm trying to figure out a way to improve the usefulness of the XO in
tablet mode by being able to configure what the keys do.
More information about the Devel