[shoelessone]

Any chance you could explain this to somebody who is just learning about HID and has run this example: https://github.com/espressif/esp-idf/tree/master/examples/pe... ? "non-boot protocol" I'm guessing is the key here? I don't have a super deep understanding of HID or what the "boot-protocol" refers to.

[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.

[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?

[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.

[platevoltage]

I'll give you my anecdote. I'm building a device that reads the input of a USB game controller. In my case, it's a Sim Steering Wheel. I ended up needing to incorporate a MAX3421e USB Host chip to read the HID input, because the ESP firmware doesn't have this implemented. Hardware wise, all ESP32 chips with hardware USB could do this, but they haven't prioritized it in software. Some keyboards and Mice use a protocol called "boot protocol", and you can get those to work. It's not very common in game controllers though.