Reputation: 664
Recently checked some Zalman keyboard, sniffing USB reports i receive this:
key '3' pressed on keyboard:
00 00 00 00 00 01 00 00 00 00 00
keys '3' + '2' pressed:
00 00 00 00 80 01 00 00 00 00 00
keys '3' + '2' + '1' pressed:
00 00 00 00 C0 01 00 00 00 00 00
My question is what is that? This is definitely not usb hid usages codes. Where i can find translation table for this? Something like that: USB HID to PS/2 Scan Code Translation Table - Microsoft
Upvotes: 0
Views: 719
Reputation: 8442
I stumbled upon this question whilst doing some research into a bug I've been having with my HID parser.
For what it's worth, I'll add a couple of points to the accepted answer, based on my interpretation of what's happening here.
In the HID Usage Table spec, it specifies the following for the Keyboard/Keypad usage page:
The usage type of all key codes is Selectors (Sel), except for the modifier keys Keyboard Left Control (0x224) to Keyboard Right GUI (0x231) which are Dynamic Flags (DV).
So, key codes are to be interpreted as Selectors.
Looking at the section that defines the Selector type (3.4.2.1), it states that Input tags with the "Sel" type will have the Array
flag set.
Till now, I've been interpreting key code fields based on the presence of the Array flag, but a random keyboard that wasn't working led me to research this a bit further.
I discovered on the re-read that the spec "sneaks" in a bit of a gotcha... an exception to the Array
rule above.
In the same section further down, it describes how selectors come in three forms. The last form is applicable to my problem:
Any selection of a set. The control is implemented as a set of bit fields in which each bit represents a single selection. This control is defined by a Main item with the Variable flag set and the Report Size equal to 1. The Report Count will be equal to the number of selections in the set.
Turns out this is the approach used to specify key codes in the problematic report descriptor.
... one bit for each useable usage id on the keyboard page, plus spares. 240 fields in the report representing each possible key code. Considering the keyboard has a key rollover of 6, it's a rather mad way of describing the reports, and I'm sure there must be something I'm missing in their rationale.
Regardless, the spec says it's fine so I've updated my HID parser to handle this case.
So I've basically reiterated what David has already stated, but I believe this is the rationale as to why it can be so.
Upvotes: 1
Reputation: 87506
It seems that each of the three keys you pressed corresponds to one bit in the report. The bit is 1 to indicate that the key is pressed and the bit is 0 to indicate that it is not pressed.
HID allows keyboards to define their own report format. You can look at the HID descriptors reported to the computer by your keyboard in order to understand what the report format is supposed to be.
Upvotes: 1