how many keys for custom HID descriptor?

flynx

29 Jul 2015, 22:48

Hi everyone,

I've been working on a sim project recently that involves wiring a ton of switches and buttons into a PC. Initially we were using keyboard encoders but the number of buttons quickly grew beyond what (i think?) we can handle with a keyboard.

If I built my own keyboard using the HID interface, and assigned a key to every possible scan code, and wrote a program to interpret those, then what would be the absolute maximum possible number of keys? (I've been researching this question for a couple weeks now and become thoroughly confused by the scan codes, HID Report Descriptors, etc.)

If the answer is "a whole butt-load of them"... then.... how is that? Has someone done this?

If the answer is "256, or what's defined in the HID usage tables"... then... why do we still use HID?

Imagine a completely custom keyboard with a mode switch. One side of the switch is HID, so you can use the keyboard in BIOS and other good places. The other side of the switch makes the keyboard act like a serial device and connects to a custom C program (once it's booted and running). Now you can do whatever you want, like having an individual key for the thousand-or-so most used kanji ideographs (image search gives good examples of this). A mode might switch to a greek layout, unicode smiley faces, etc. These are just examples.

I don't want to argue about the usability, application, or practicality of this type of keyboard. I'm just trying to fully understand the limitations of the HID interface.

Thanks
flynx

User avatar
Muirium
µ

29 Jul 2015, 22:58

The USB Human Input Device spec is what it is. USB came out in the 90s, and they needed to support keyboards, so they pretty much just copied what PS/2 keyboards of the time could do already. Such is the life of standards! Japanese users were already using keyboards very similar looking to American and European models. No one was pushing for a wild solution, so they didn't make one.

Of course, if you care to do the work yourself, you could always write a driver and go nuts. But that same bother (and the need to do it again and again to support different platforms) is the stumbling block that's kept everyone on the lowest common denominator: USB HID.

Findecanor

30 Jul 2015, 01:00

USB allows you to have multiple interfaces, each interface being like a virtual device. That would allow you to send a regular HID keyboard report and another protocol at the same time. If you have a driver for your new keyboard protocol on the host side, then it could tell the keyboard to shut off the regular interface.
Soarer's firmware does something like that, but within the rules of the USB HID protocol to achieve both BIOS compatibility and N-key rollover at the same time: there are two keyboard interfaces that are configured differently so as to be mutually exclusive: one interpreted only by BIOS:es and one interpreted only by capable USB HID drivers.

HID allows you to send any key as a bit in a bitfield. That is how the modifiers are sent in the classic 6KRO "boot protocol", but it can really be used for any key. . How each packet is made is defined in a "report descriptor" that the host requests after the keyboard has been connected. The report descriptors are the biggest problem, and the biggest strength with HID: they are written in a kind of language, and that language has to be interpreted ... and that is complex and ripe with chance of interpreting things differently.

Many keyboards (and keyboards over Bluetooth) use the 6KRO protocol because they are using low-speed USB and it has a limit of eight bytes payload per packet, but it is possible to send multiple packets with the first byte being dedicated as "report ID".
The Noppoo Choc keyboard does N-key rollover that way: as multiple 8-byte packets over low-speed USB.
The problem that keyboard has on Macintosh is not actually that it does so, but because of some weirdness in its report descriptor that confuses Apple's parser.

Post Reply

Return to “Keyboards”