On Mon, 2005-05-02 at 10:10 -0700, Shaun Jackman wrote:
> If we label raw as bits 0..31 and raw as bits 32..63 we have
> key =3D bits 44..51
> key =3D bits 36..43
> key =3D bits 28..35
> key =3D bits 24..31
> key =3D bits 16..23
> key =3D bits 8..15
I don't think anyone has a compete picture of exactly how the keyboard
is supposed to work (though I think groepaz is closest).
In the case of the cheap third party adaptors (which is what I think you
have) the keyboard scan codes appear in bits 24..31 if a single key is
pressed, bits 16..31 when two keys are pressed and bits 8..31 when three
keys are pressed. My patch lets Linux read those three bytes and I left
the original code unmodified to try and stop my patch breaking real
Nintendo keyboards (unfortunately I haven't found anyone else with a
keyboard that can test my patch on so it hasn't yet been offered for
I assumed that the register protocol permits keyboards to have up to six
keys pressed simultaneously but that PC derived keyboard controllers
can't support than many keys. This allows different keyboard to stash
their scan codes in different parts of the register space. I would add
that never having seen a Nintendo keyboard that this is purely
speculation on my part.
> This table shows the overlap of bits 28..31, as well as the undecoded
> bits 0..7 and 52..63. Is there any information transmitted in those
> undecoded bits?
I've no idea what these bits do and groepaz's YAGD is also unsure. Oddly
enough bits 0..29 are undocumented here but some of these bits are used
in the Linux keyboard driver.
Daniel Thompson (Merlin) <daniel@...>
Did Sigmund's wife wear Freudian slips?