HID standard
The HID standard was adopted primarily to enable innovation in PC input devices and to simplify the process of installing such devices. Prior to the introduction of the HID concept, devices usually conformed to strictly defined protocols for mouse, keyboards and joysticks; for example, the standard mouse protocol at the time supported relative X- and Y-axis data and binary input for up to two buttons, with no legacy support. All hardware innovations necessitated either overloading the use of data in an existing protocol or the creation of custom device drivers and the evangelization of a new protocol to developers. By contrast, all HID-defined devices deliver self-describing packages that may contain any number of data types and formats. A single HID driver on a computer parses data and enables dynamic association of data I/O with application functionality, which has enabled rapid innovation and development, and prolific diversification of new human-interface devices.
A working committee with representatives from several prominent companies developed the HID standard. The list of participants appears in the "Device Class Definition for Human Interface Devices (HID)" [1] document. The concept of a self-describing extensible protocol initially came from Mike Van Flandern and Manolito Adan while working on a project named "Raptor" at Microsoft, and independently from Steve McGowan, who worked on a "SIM" project that defined a device protocol for the VFX1 VR Headset and its peripherals based on ACCESS.bus while at Forte Technologies. SIM was also self-describing and extensible, however it was more focused on SIMulation devices used for VR and motion capture. After comparing notes at a Consumer Game Developer Conference, Steve and Mike agreed to collaborate on a new standard for the emerging Universal Serial Bus (USB).
Prior to HID (c.1995), proprietary drivers needed to be installed for almost every device attached to a PC. This meant that device vendors needed to track OS releases, and regularly offer updated drivers for their devices, and to develop drivers for each OS that they wanted to support. Also, at the time any novel devices, e.g., Joysticks designed for flight simulators with extra buttons or D-pads, required software support not only by the driver, but by each game that supported them to enable new controls. This meant that the device developers had the additional responsibility of enabling each game that they wanted to support. The ability for a HID device to describe itself via a Report Descriptor, decoupled hardware device developers from game developers. The Report Descriptor concept also meant that OS vendors could write a HID driver (Parser) that could accommodate almost any HID device a vendor could dream up, without the vendor needing to write or maintain a driver for every OS that they wanted to support.
So the HID class decoupled device vendors from game and OS vendors, enabling device vendors to innovate faster, and reducing their development costs (e.g., no drivers or game developer support). The HID Usage Table document defines thousands of controls that can be presented by HID devices. Game vendors can query the OS's HID parser to identify the set of controls that are presented by a device, then map those controls to features in their game. Since its original release, the HID Usage Table (HUT) document has had hundreds of new uses added to it.
The HID protocol has its limitations, but all modern mainstream operating systems will recognize standard USB HID devices, such as keyboards and mice, without needing a specialized driver. However its versatility has been demonstrated by the fact that it has not been updated in over 22 years, and it is still supported by every PC, tablet and cell phone in production today. USB, hence HID, devices can be hot-plugged, so when installed, a message saying that "A 'HID-compliant device' has been recognized" generally appears on screen. In comparison, this message did not usually appear for devices connected via the PS/2 6-pin DIN connectors which preceded USB. PS/2 did not typically support plug-and-play, which means that connecting a PS/2 keyboard or mouse with the computer powered on does not always work and may pose a hazard to the computer's motherboard. Likewise, the PS/2 standard did not support the HID protocol. The USB human interface device class describes a USB HID.
The HID protocol (Report Descriptor and Report mechanism) has been implemented on many buses other than USB, including Bluetooth and I2C.
There are also a number of extensions to HID defined in "HID Integrated Usage Table Documents", including uninterruptible power supplies, video monitor controls, point of sale devices, arcade and gaming (slot machines) devices.
Report Descriptor
The Report Descriptor exposes the messages that are generated or accepted by a HID device. Each message is referred to as a 'Report'. Reports can define bits/controls in a device that can be read or written, or generated periodically to keep a host updated on the current status of the device. For instance, a mouse typically generates a Report 200 times a second to inform the host of any movement or button presses. Report Descriptors are 'bit orientated', meaning that controls can present between 1 and 32 bits of information. Each control defined in a Report Descriptor has an ID and defines its size and position in its Report. A Report Descriptor can define many Reports, each reporting a different set, or combination of information.
For example, a basic mouse defines a 3 byte Report where the least significant (0) bit of the report is the left button, the next (1) bit is the middle button, and the third (2) bit is the right button. To allow the mouse 8-bit X and Y position coordinates to conveniently land on byte boundaries, a 5-bit 'pad' is defined. Then the X coordinate is defined as an 8-bit relative value (i.e., number of 'mickeys' since the previous report) that resides in bit positions 8 through 15, and the Y coordinate is defined as an 8-bit relative value that resides in bit positions 16 through 24, resulting in a data packet that is presented to the host.
A Report Descriptor is extremely versatile, allowing a device to specify the resolution, range, and many other characteristics of each control that it presents. Being designed at a time when a mouse or keyboard controller was lucky to have 1KB of ROM for all its code and data, the Report Descriptor syntax has many features that allow its size to be minimized e.g., selected control parameters can persist across control multiple definitions, only needing to be redeclared if their value changes. The reports generated by a basic mouse can be described in 50 bytes, and a 104 keyboard in 65 bytes.
Physical Descriptor
A little known or understood feature of HID is the Physical Descriptor. The Physical Descriptor is used to define the parts of the human body that interact with the individual controls defined in the Report Descriptor. When controlling a game, the index finger and thumb are usually used to invoke repetitive actions. Because these fingers are considered to have the fastest 'twitch' response, they are typically used for pulling the trigger of a gun, or activating an often used game function. The Physical Descriptor allows a device vendor identify that which fingers rests on each control and prioritize the set of controls that can be reached by an individual finger. This feature enables a game vendor to intelligently present the best default button mapping, even for a device that didn't exist when the game was developed. The Physical Descriptor also enables full body motion capture information to be presented by a HID device, i.e., the angle, orientation, relative or absolute position of any joint in the human body. And through the Report Descriptor, the motion capture data can be presented at whatever resolution that the device can support.
Components of the HID protocol
In the HID protocol, there are 2 entities: the "host" and the "device". The device is the entity that directly interacts with a human, such as a keyboard or mouse. The host communicates with the device and receives input data from the device on actions performed by the human. Output data flows from the host to the device and then to the human. The most common example of a host is a PC but some cell phones and PDAs also can be hosts.
The HID protocol makes implementation of devices very simple. Devices define their data packets and then present a "HID descriptor" to the host. The HID descriptor is a hard coded array of bytes that describes the device's data packets. This includes: how many packets the device supports, the size of the packets, and the purpose of each byte and bit in the packet. For example, a keyboard with a calculator program button can tell the host that the button's pressed/released state is stored as the 2nd bit in the 6th byte in data packet number 4 (note: these locations are only illustrative and are device-specific). The device typically stores the HID descriptor in ROM and does not need to intrinsically understand or parse the HID descriptor. Some mouse and keyboard hardware in the market today is implemented using only an 8-bit CPU.
The host is expected to be a more complex entity than the device. The host needs to retrieve the HID descriptor from the device and parse it before it can fully communicate with the device. Parsing the HID descriptor can be complicated. Multiple operating systems were known to have shipped bugs in the device drivers responsible for parsing the HID descriptors years after the device drivers were originally released to the public. However, this complexity is the reason why rapid innovation with HID devices is possible.
The above mechanism describes what is known as HID "report protocol". Because it was understood that not all hosts would be capable of parsing HID descriptors, HID also defines "boot protocol". In boot protocol, only specific devices are supported with only specific features because fixed data packet formats are used. The HID descriptor is not used in this mode so innovation is limited. However, the benefit is that minimal functionality is still possible on hosts that otherwise would be unable to support HID. The only devices supported in boot protocol are
- Keyboard – Any of the first 256 key codes ("Usages") defined in the HID Usage Tables, Usage Page 7 can be reported by a keyboard using the boot protocol, but most systems only handle a subset of these keys. Most systems support all 104 keys on the IBM AT-101 layout, plus the three extra keys designed for Microsoft Windows 95 (the left and right Windows key, and the Menu key). Many systems also support additional keys on basic western European 105-, Korean 106-, Brazilian ABNT 107- and Japanese DOS/V 109-key layouts. Buttons, knobs and keys that are not reported on Usage Page 7 are not available. For example, a particular US keyboard's QWERTY keys will function but the Calculator and Logoff keys will not because they are defined on Usage Page 12 and cannot be reported in boot protocol.
- Mouse – Only the X-axis, Y-axis, and the first 3 buttons will be available. Any additional features on the mouse will not function.
One common usage of boot mode is during the first moments of a computer's boot up sequence. Directly configuring a computer's BIOS is often done using only boot mode. Sometimes a message will appear informing the user that the device has installed the correct driver and is now usable.
Definition of a device
According to the HID specification, a device is described, during the report mode, as a set of controls or group of controls. Controls are matched by a field containing the data, and another containing a usage tag. Each usage tag is described in the spec as the constructor suggested use of the data described in the report mode.
The HID Descriptor Tool (#External links) is a Windows app that can be used to generate all the descriptors associated with a HID device (see link below). It performs syntax checking, and can generate C, C Header and binary files for the HID descriptors. Its text-based Usage Table definion files can also be easily extended to define proprietary Usages (control types) or Usage Tables (the set of Usages associated with a device or feature).
