3 ms·

USB HID deevice class definition [pdf]

23 points by fanf2 2y ago

jauntywundrkind 2y ago
There is a ton more in here than one might at first guess. I happened to scan through it a couple years back, and was shocked to find out power sources (chargers, batteries) and sinks could be reporting all kinds of power telemetry like capacity, current charge, amperage, voltages... Tons of things. There's all kinds of sensors & systems! I'd always thought of HID as keyboard + mouse, but it's actually quite a broadscale system. It just so happens we - for the most part - never used 98% of it. (Then had to reinvent a bunch of the power reporting stuff for usb-pd.)
- SSLy 2y ago
  The HID was also taken wholesale and put on top of Bluetooth, right?
  - mrcsharp 2y ago
    Yes, with adjustments to make it work with the bluetooth stack. It makes sense. No need for a different input stack implementation in the OS to handle common peripherals like Keyboards and Mice just because they are using a different communication medium. HID works well for this.
    - Findecanor 2y ago
      I wouldn't have designed the Bluetooth mouse protocol like this though. HID uses relative movements since the last packet ... and with radio interference, Bluetooth packets get lost.
- petee 2y ago
  The APC smart UPS line implements quite a few metrics and settings via HID, and were kind enough to document it (application note 178) The standard does seem to allow for some complex setups which is pretty cool.
zdw 2y ago
Title has an extra e?
- badgersnake 2y ago
  And it’s from [2001]
- fanf2 2y ago
  I think my HID deevice must have bad debouncing.
deleted 2y ago
[deleted]
mrcsharp 2y ago
This document was essential when I implemented Bluetooth Keyboard & Mouse HID support in nanoFramework [1] to automatically lock my PC based on my presence [2]. I found this doc difficult to read at times and has some vague parts where I had to look at existing open-source implementations in other languages to understand the feature/functionality more. However, I was pleasantly surprised by how good the HID protocol is and how much it does behind the scenes to enable the peripherals we use everyday. I would argue that it needs a new iteration. Some of the modern peripherals like gaming mice have extra functionality that you need to install the OEM's software which is just additional bloat. A new iteration of this protocol could bring some/all of the common modern functionality natively to operating systems and reduce our reliance on extra software that just boats the operating system and slows things down. [1]: https://www.nanoframework.net/ https://www.nanoframework.net/ [2]: https://blog.mrcsharp.dev/post/automatically-lock-pc-using-nanoframework/ https://blog.mrcsharp.dev/post/automatically-lock-pc-using-n...

23 points by fanf2 2y ago

There is a ton more in here than one might at first guess. I happened to scan through it a couple years back, and was shocked to find out power sources (chargers, batteries) and sinks could be reporting all kinds of power telemetry like capacity, current charge, amperage, voltages... Tons of things. There's all kinds of sensors & systems! I'd always thought of HID as keyboard + mouse, but it's actually quite a broadscale system. It just so happens we - for the most part - never used 98% of it. (Then had to reinvent a bunch of the power reporting stuff for usb-pd.)

SSLy 2y ago
The HID was also taken wholesale and put on top of Bluetooth, right?
- mrcsharp 2y ago
  Yes, with adjustments to make it work with the bluetooth stack. It makes sense. No need for a different input stack implementation in the OS to handle common peripherals like Keyboards and Mice just because they are using a different communication medium. HID works well for this.
  - Findecanor 2y ago
    I wouldn't have designed the Bluetooth mouse protocol like this though. HID uses relative movements since the last packet ... and with radio interference, Bluetooth packets get lost.
petee 2y ago
The APC smart UPS line implements quite a few metrics and settings via HID, and were kind enough to document it (application note 178) The standard does seem to allow for some complex setups which is pretty cool.

zdw 2y ago

Title has an extra e?

badgersnake 2y ago
And it’s from [2001]
fanf2 2y ago
I think my HID deevice must have bad debouncing.

deleted 2y ago

[deleted]

mrcsharp 2y ago

This document was essential when I implemented Bluetooth Keyboard & Mouse HID support in nanoFramework [1] to automatically lock my PC based on my presence [2]. I found this doc difficult to read at times and has some vague parts where I had to look at existing open-source implementations in other languages to understand the feature/functionality more. However, I was pleasantly surprised by how good the HID protocol is and how much it does behind the scenes to enable the peripherals we use everyday. I would argue that it needs a new iteration. Some of the modern peripherals like gaming mice have extra functionality that you need to install the OEM's software which is just additional bloat. A new iteration of this protocol could bring some/all of the common modern functionality natively to operating systems and reduce our reliance on extra software that just boats the operating system and slows things down. [1]: https://www.nanoframework.net/ https://www.nanoframework.net/ [2]: https://blog.mrcsharp.dev/post/automatically-lock-pc-using-nanoframework/ https://blog.mrcsharp.dev/post/automatically-lock-pc-using-n...