The Human Interface Device class, often called HID, supplies a framework for reporting controls and input data. Keyboards and pointing devices are familiar examples, but the model can describe many other types of controls.
How the pieces connect
A report descriptor explains how the device's data is organized and what its fields represent. The host interprets reports through the supported class path. This separates a common transport and description mechanism from the individual meanings of buttons, axes, or other values. A product can also expose additional non-HID interfaces for unrelated functions.
An everyday example
A headset's media buttons can appear through an input-related function even though its primary purpose is audio. A controller with several axes can use the same broad class framework while producing very different reports from a keyboard. Shared class membership does not imply that applications will present the controls identically.
Reading the information in context
HID describes an interface model, not a guarantee of every application feature or a promise about custom lighting and macro functions. Optional vendor controls may use another path. Consult the product's manufacturer documentation for those distinctions. The library does not record keystrokes or ask readers to grant input-device access in order to explain the terminology.
USB & Peripherals
Note these before you change anything
Useful facts to have to hand while reading about human interface device classes.
- Which port the device was in, and whether a hub is involved
- The device's name and status in Device Manager
- Power management settings on USB root hubs
- Any companion software the device relies on
USB & Peripherals: Input from a device (output devices run the other way)
- Devicekeyboard, mouse or pad
- Port or hubphysical connection
- Host controllermanages the bus
- Class driverfor example HID
- Applicationreceives the input
