[thequux]

The USB HID protocol is designed to support basically any device that regularly reports a set of values; those values can represent which keys are pressed, how a mouse has moved, how a joystick is positioned, etc. Now, different devices have different things that they support: joysticks have varying numbers of axes, mice have different sets of buttons, some keyboards have dials on them, etc. So, there's no single format for a report that simultaneously efficiently uses bandwidth and supports all the things a human interface device might do. To solve this, the HID protocol specifies that the host can request a "report descriptor" that specifies the format and meaning of the status reports. This is great for complex devices running a full OS; there's plenty of memory and processing power to handle those varying formats. However, these HID devices needed to also work in very limited environments: a real mode BIOS, microcontroller, etc. So, for certain classes of device such as keyboards and mice, there is a standard but limited report format called the "boot protocol". IIRC, the keyboard version has space to list 6 keys that are pressed simultaneously (plus modifiers), all of which must be from the same table of keys in the spec, and the mouse has an dX and dY field plus a bitfield for up to 8 buttons (four of which are the various ways you can scroll). To implement a more complex device, you'd want to be able to specify your own report format, which the ESP driver doesn't seem to allow you to do.

[tomcam]

That was a virtuoso explanation! You’ve solved about 25 years of USB questions I’ve had in one post. Thank you very much.

[lloeki]

Take an afternoon to play around talking to devices through libusb.

It was an eye opener for me.

Language does not matter (I used Go and Ruby) as long as bindings are reasonable.

[shoelessone]

Thanks for taking the time to explain!

So your original comment / request was regarding USB specifically then?

I ask because I'd have guessed (possibly incorrectly!) that implement HID via GATT (BLE) you'd be able to support anything the BLE hardware revision could implement?

Perhaps the disconnect for me is that it's unclear when there is some special hardware that exists within the ESP32 itself (I think I2C, I2S, etc would be examples of this) vs something you are just implementing by manipulating the IO pins. Perhaps HID is one of those things?

[jononor]

The BLE and USB peripherals are separate, so limitations in USB HID do not carry over to BLE HID.

[philsnow]

Is this why certain USB keyboards I have don't seem to do anything in BIOS? I keep around a really dumb/boring dome keyboard for this purpose.

[tialaramex]

Maybe. If you have Linux the command `lsusb -v` gives you a verbose breakdown of the attached USB devices, if you find your keyboard it will show which interfaces it provides (a USB device can offer several if it wants) and to work at boot you want:

interface class 3 (a Human Interface Device) sub class 1 (Boot protocol or Boot interface)

In contrast the sub class 0 of HID is just the ordinary case, which is arbitrarily complicated (six thousand keys and four axis input? Why not) and so understandably a BIOS or similar environment might not implement that but a full blown OS usually does.

Doubtless tools exist for other platforms which can show the same information as lsusb