A human interface device or HID is a type of computer device that interacts
directly with, and most often takes input from, humans and may deliver
output to humans. The term "HID" most commonly refers to the USB-HID
specification. The term was coined by Mike Van Flandern of Microsoft when he
proposed the USB committee create a Human Input Device class working group.
The working group was renamed as the Human Interface Device class at the
suggestion of Tom Schmidt of DEC because the proposed standard supported
bi-directional communication. 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 mice, 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" 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 device protocol for Access Bus while at Forte. 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.
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. When installed, a message saying that "A
"HID-compliant device" has been recognized" generally appears on screen.
In comparison, this message does not usually appear for devices connected via
the PS/2 6-pin DIN connectors which preceded USB. PS/2 does 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 does not support the HID
protocol. The USB human interface device class describes a USB HID.
= 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 describe 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. 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 are 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 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. 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. = HID 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. Other protocols using HID
Since HID's original definition over USB, HID is now also used in other
computer communication buses. This enables HID devices that traditionally
were only found on USB to also be used on alternative buses. This is done since
existing support for USB HID devices can typically be adapted much faster than
having to invent an entirely new protocol to support mice, keyboards, and
the like. Known buses that use HID are: Bluetooth HID — Bluetooth is a wireless
communications technology. Bluetooth mice and keyboards are becoming
increasingly common. Serial HID — Used in Microsoft's Windows
Media Center PC remote control receivers.
ZigBee input device - ZigBee RF4CE supports HID devices through the ZigBee
input device profile. IRCF360 a 360 degree / 3D motion sensor
used as a HID device HID over I2C - Used for embedded devices
in Microsoft Windows 8 See also
Human interface guidelines Human-computer interaction
USB human interface device class Graphical user interface builder
Linux on the desktop Peripheral
References External links
HID developers forum, USB.org HID Device Class Definition 1.11
Specification, USB.org HID Usage Tables 1.12 Specification,
USB.org