USB human interface device class

From Wikipedia, the free encyclopedia

You have new messages (last change).

The USB human interface device class ("USB HID class") is a USB device class that describes human interface devices such as computer keyboards, computer 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. There are a number of other documents that describe more specific devices in the HID class.

Contents

[edit] 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.

[edit] Keyboards

Keyboards are some of the most popular USB HID class devices. The USB HID class keyboard has replaced the PS/2 keyboard on most modern computer systems. 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.

[edit] Mice

Computer mice are equally popular USB HID class devices. Much like keyboards, USB HID class mice have replaced PS/2 mice on many modern computer systems. 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; mice with extended functionality require custom drivers from the manufacturer.

[edit] 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.

[edit] Other devices

The USB HID class specifications allow for a myriad of other devices under the USB HID class. Some examples are automobile simulation controllers, exercise machines, telephony devices, audio controls, medical instrumentation and even magic carpet simulators. 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.

[edit] 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.

[edit] Logical specifications

[edit] 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 (e.g. a USB telephone may use a HID keypad and an audio speaker.)

The interface devices are also defined with subclass descriptors. The subclass descriptor is used to declare a device bootable. A bootable device meets a minimum adherence to a basic protocol and will be recognized by a computer 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.

[edit] Reports

It is impossible to accurately predict and define all current and future human interface devices. Because of this, the USB HID class requires that every device describes how it will communicate with the host device. 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 well-defined by manufacturers such as Microsoft. When a vendor makes a custom USB HID class device, the reports formed by the device need only 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.


[edit] USB HID API

The USB HID API is very complicated and can be difficult to understand, even for doing the most basic things. Much of it can be ignored for almost all users, the hard part is knowing what to ignore.

There are two levels of APIs related to USB HID: the USB level and the OS level. At the USB level, there is a protocol for devices to announce their capabilities and the OS to parse the data it gets.

Every OS has a HID API to enable programs to interact with USB HID devices. Many of the same concepts apply when trying to get HID data.

[edit] Jargon

There is also quite a bit of jargon specific to the USB HID API.


[edit] usage

A usage is a descriptive tag for a single element of a device. For example: "trigger", "x axis", "slider", or "throttle".

[edit] usage page

The USB HID API includes a very long list of usages, which are organized into "usage pages". A usage page is a group of related usages. The most commonly used usage page is "generic desktop", which includes an X, Y, and Z axis, "dial", "slider", etc.

[edit] collection

A collection is a set of usages grouped into common device types, for example joystick, gamepad, or the more general pointer.

[edit] descriptor

A descriptor is a special report from the device to the host computer that describes that device in terms of usages, usage pages, and collections. The descriptor tells the host computer the data format coming from the device, laid out in byte-deliniated chunks. If the data doesn't fit neatly into bytes, it must be padded with constants to make it fit into bytes.

[edit] on/off control

An on/off control is a usage that only has two states. A single bit is used to send state of an on/off control.

[edit] dynamic value

A dynamic value is a usage that changes over a range of values. It can be up to one byte in size (8-bit, 0 to 255 or -127 to 127).

[edit] feature report

[edit] logical min/max

[edit] External links

Retrieved from "http://en.wikipedia.org../../../u/s/b/USB_human_interface_device_class_be15.html"