Human Interface Devices (HID)

Human Interface Device reports describe controls through declared report layouts and usages, which a host interprets before applications assign actions.

HID, Human Interface Device, provides a structured way to describe and report controls. Its use includes keyboards, pointers, gamepads and media-control devices.

The report’s declared layout and usages tell a host what its fields mean. The receiving application then gives those controls an action in its own context.

A descriptor describes; a report supplies state

A report descriptor defines properties such as field sizes, ranges, collections and usages. An input report supplies values using that established layout.

Reading a byte as an arbitrary key number without its descriptor can give the wrong meaning. The same bit pattern can represent a button, an axis value or padding under different layouts.

The USB HID class specification defines its USB contract. Other transports, including supported Bluetooth profiles, can carry HID-related report arrangements through their own contracts.

Usage pages qualify the control identifier

USB-IF’s Usage Tables place controls into usage pages. The Consumer page has identifier 0x0C; its Play/Pause usage is 0xCD.

Those identifiers describe a control meaning, not the label painted on every handset or a guarantee that every host/application exposes it.

A keyboard key and a Consumer Play/Pause control are consequently different declarations even when an application maps both to a playback action.

An original one-bit report model

This readable teaching object defines one media-control field:

{
  "usagePage": 12,
  "usage": 205,
  "logicalRange": [0, 1],
  "inputBits": 1,
  "paddingBits": 7
}

It is not a native HID report descriptor or a device capability capture. The decimal identifiers correspond to the Consumer/Play-Pause meanings above.

For this original declared one-byte arrangement, with the control in the least significant bit:

Report byte Declared control state
00 Not asserted
01 Asserted

Seven other bits are padding in this model. A real descriptor can define more controls, report IDs and other layouts; the host must parse that actual declaration.

An assertion is not an instruction to toggle continuously

Polling an asserted report several times does not necessarily mean the user pressed the button several times.

For an original sequence 00, 01, 01, 00, the control has one transition from unasserted to asserted. A toggle action can therefore run once rather than once per asserted sample.

A navigation action can intentionally use a repeat policy. A continuous analog action can use another policy again. HID reports provide input meaning/state; application behavior decides the operation.

The focused route determines the result

The operating system can consume a media control globally or route it to an application. A UI view can also assign a control differently while a movie is playing than while the user browses a library.

For Emby, a device recognized as HID is only early evidence. The host event, app focus and current action mapping determine whether a press actually pauses, navigates or does something else.

Keyboard and remote support describes the app’s control surface. Gamepad input adds axis values and mapping decisions beyond a single media button.

See Also

References