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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel