In computing, the USB human interface device class (USB HID class) is a part of the USB specification for computer peripherals: it specifies a device class (a type of computer hardware) for human interface devices such as keyboards, mice, game controllers and alphanumeric display devices.
The USB HID class is defined in a number of documents provided by the USB Implementers Forum's Device Working Group. The primary document used to describe the USB HID class is the Device Class Definition for HID 1.11.
Devices
The USB HID class describes devices used with nearly every modern computer. Many predefined functions exist in the USB HID class. These functions allow hardware manufacturers to design a product to USB HID class specifications and expect it to work with any software that also meets these specifications.
The same HID protocol is used unmodified in Bluetooth human interface devices. The Bluetooth profile specification only points readers to the USB HID documentation. In this sense those devices also belong to the USB HID class.
Keyboards
Keyboards are some of the most popular USB HID class devices. The USB HID class keyboard is normally designed with an IN endpoint that communicates keystrokes to the computer and an OUT endpoint that communicates the status of the keyboard's LEDs from the computer to the keyboard. The PC 97 standard requires that a computer's BIOS must detect and work with USB HID class keyboards that are designed to be used during the boot process.
Keyboards that implement the USB Boot Keyboard profile specified in the USB Device Class Definition for Human Interface Devices (HID) v1.11 and are explicitly configured to use the boot protocol will interrupt the CPU every time the keyboard is polled even if there is no change in state unless the USB controller overrides this behavior, and are limited to 6-key rollover (6KRO). This profile is intended to allow the BIOS to handle a USB keyboard in the absence of a USB-aware operating system. The recommended profile for keyboards that are not in boot mode in this specification limits keyboards to 6KRO and causes them to respond to an interrupt with a status report at least every half second even if there is no state change in the keyboard unless the USB controller overrides this behavior in order to implement typematic (the function that causes keys to repeat when they are held long enough). However, keyboards in non-boot mode are free to implement an alternative HID profile.
The above described behavior is in contrast to the PS/2 interface, which supports n-key rollover (NKRO) for keyboards capable of supporting NKRO. The PS/2 interface does not interrupt the CPU at all when there are no state changes except when a key is held long enough to activate typematic, which causes the keyboard to repeatedly send the scan codes for the keys held down long enough in order to cause the keys to repeat themselves. This behavior of not having to respond to repeated polling saves power, so the PS/2 interface is often used in laptops' internal keyboards.
Mice
Computer mice are another popular USB HID class devices. USB HID mice can range from single-button simple devices to multi-button compound devices. Most modern operating systems ship with drivers for standard HID mice designs (the most common modern mouse design has two dedicated buttons and a mouse wheel that doubles as the third button); mice with extended functionality require custom drivers from the manufacturer.
USB mice have lower latencies than PS/2 mice because standard USB mice are often polled at a default rate of 125Â Hz while standard PS/2 mice send interrupts at a default rate of 100Â Hz when they have data to send to the computer. Also, USB mice do not cause the USB controller to interrupt the system when they have no status change to report according to the USB HID specification's default profile for mice. Both PS/2 and USB allow the sample rate to be overridden, with PS/2 supporting a sampling rate of up to 200Â Hz and USB supporting a polling rate up to 1Â kHz as long as the USB mouse runs at full-speed or higher USB speeds.
As a result of the PS/2 mouse interface's interrupt-driven nature that does not require periodic polling, PS/2 interface saves power, which makes it a popular choice for pointing devices integrated into laptops.
Game controllers
Modern game controllers and joysticks are often USB HID class devices. Unlike legacy game port devices, USB HID class game devices do not normally require proprietary drivers to function. Nearly all game devices will function using onboard drivers as long as the device is designed around the drivers and the USB HID class specifications.
Other devices
The USB HID class specifications allow for myriad other devices under the USB HID class. Some examples are automobile simulation controllers, exercise machines, telephony devices, thermometers, FluoShoes, audio controls and medical instrumentation. Even uninterruptible power supplies and software protection dongles declare themselves under this class, despite the fact they often have no human interface at all. Any device can be a USB HID class device as long as a designer meets the USB HID class logical specifications. This is not to say that there is no need to ship drivers for these devices, nor that an operating system will immediately recognize the device. This only means that the device can declare itself under the human interface device class.
Security vulnerabilities
The USB interface is vulnerable to security exploits such as BadUSB that abuse the combination of USB's ability to connect many different kinds of devices, its inability to verify that devices are actually what they claim to be, the possibility for USB devices to change their type or announce additional subdevices while plugged in, and its default behavior of accepting any device that connects to it. As a partial countermeasure, PS/2 peripherals may be used instead together with disabling all USB ports.
Drivers
One of the benefits of a well-defined specification like the USB HID class is the abundance of device drivers available in most modern operating systems. The USB HID class devices and their basic functions are defined in USB-IF documentation without any specific software in mind. Because of these generic descriptions, it is easy for operating system designers to include functioning drivers for devices such as keyboards, mice, and other generic human interface devices. The inclusion of these generic drivers allows for faster deployment of devices and easier installation by end-users.
Logical specifications
Functional characteristics
The USB human interface device class can be used to describe both device and interface classes. The interface class is used when a USB device can contain more than one function. It is possible, therefore, to have USB devices with two different interfaces at the same time (for example, a USB telephone may use a keypad covered by the HID class and a speaker covered by the USB audio device class).
The interface devices are also defined with subclass descriptors. The subclass descriptor is used to declare a device bootable. A boot device meets a minimum adherence to a basic protocol and will be recognized by a computer's BIOS.
Each USB HID interface communicates with the host using either a control pipe or an interrupt pipe. Isochronous and bulk pipes are not used in HID class devices. Both IN and OUT control transfers are required for enumeration; only an IN interrupt transfer is required for HID reports. OUT interrupt transfers are optional in HID-class devices.
Reports
The USB HID class requires that every device describes how it will communicate with the host device in order to accurately predict and define all current and future human interface devices. During enumeration the device describes how its reports are to be structured so that the host device can properly prepare to receive this information.
The host periodically polls the device's interrupt IN endpoint during operation. When the device has data to send it forms a report and sends it as a reply to the poll token. Common devices such as keyboards and mice send reports that are compliant with standards set by the USB Implementers Forum (USB-IF). When a vendor makes a custom USB HID class device, the reports formed by the device need to match the report description given during enumeration and the driver installed on the host system. In this way it is possible for the USB HID class to be extremely flexible.
USB HID API
There are two levels of APIs related to USB HID: the USB level and the operating system level. At the USB level, there is a protocol for devices to announce their capabilities and the operating system to parse the data it gets. The operating system then offers a higher-level view to applications, which do not need to include support for individual devices but for classes of devices. This abstraction layer allows a game to work with any USB controller, for example, even ones created after the game.
See also
- USB On-The-Go (OTG)
References
External links
- USB.org: the homepage of the USB Implementers Forum, Inc.
- USB in a Nutshell
- Microsoft Related HID Documentation: the USB-IF's collection of Microsoft's HID documentation
- USB-IF HID Tools: the USB-IF's page devoted to human interface devices, includes all approved documentation
- Lakeview Research HID Page: a collection of articles about, and example code for USB HID devices.
- PC System Guides: Microsoft's PC System specifications (e.g. PC '97, PC '98)