From Wikipedia, the free encyclopedia - View original article
|This article needs additional citations for verification. (November 2009)|
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.
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.
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.
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.
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.
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.