Archive: Hardware IDs for HID Devices

Updated: March 12, 2002

On This Page

  Introduction
  HID Over USB
  References for HID

Introduction

The Human Interface Device (HID) class was originally developed by the USB Device Working Group. This protocol standard includes support for keyboards, mouse and pointing devices, joysticks, game pads, and other types of input devices. Although HID was originally developed for use over USB, the protocol is theoretically not dependent on any specific bus and can be ported over to other buses.

Microsoft supports HID over USB on Microsoft Windows 98 Gold, Windows 98 Second Edition, Windows Millennium Edition, Windows 2000, Windows XP operating systems, and Microsoft Windows Server 2003 operating systems, and will continue to support it on future versions of Windows. For more information about the architecture for HID in Windows, see the Interactive Input Devices section in the Windows Driver Development Kit (DDK).

This article provides information about the hardware enumeration process for Human Input Devices (HIDs), and it identifies the hardware identifiers (IDs) that vendors should use to identify their device in INF files for use with the Windows family of operating systems.

 Top of page

HID Over USB

This section is dedicated to the Human Interface Device enumeration process on the Universal Serial Bus.

Device Identification Strings for USB Devices

When a USB HID device is initially plugged in to a Windows-based computer, the Windows USB stack enumerates the device, extracting details from the device and the interface descriptor (or descriptors) of the device, and then generates a set of hardware IDs and compatible IDs for the device.

For a complete list of USB hardware IDs, see the "Device Identification Strings" section under Device Installation in the Windows XP DDK.

The examples in the following sections show two scenarios:

• USB IDs for a single interface USB device

• USB IDs for a multi-interface (composite) USB device

Example 1: USB IDs for a Single Interface USB Device

This example shows how the hardware IDs and compatible IDs are generated for a single-interface USB device on a system running Windows 2000 or Windows XP.

When the device is originally enumerated by the USB stack, the Usbhub driver extracts idVendor, idProduct, and bcdDevice from the device descriptor. These three fields are incorporated to generate a USB hardware ID. Note that the vendor, device, and revision numbers are always stored in hexadecimal format.

The generation of the compatible ID for the device is more complicated. The class code, subclass code, and protocol code are determined by the interface descriptor's bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol. These values are in two-digit hexadecimal format.

Vendors should only use Hardware ID matching in their INFs. Items that are not identified in bold in Table 1 should not be used by vendors in their INFs.

Table 1: Device Identification Strings for a Single-Interface Device

Example 2: USB IDs for a Multi-Function (composite) USB Device

Devices with multiple functions are called composite devices. This example shows how the hardware IDs and compatible IDs are generated for composite USB devices on Windows 2000, Windows XP, and Windows Server 2003. When a new USB composite device is plugged into a computer system running Windows, the USB hub driver creates a physical device object (PDO) and notifies the operating system that its set of child devices has changed. After querying the hub driver for the hardware IDs associated with the new PDO, the system searches the appropriate INF files to find a match for the identifiers. If a vendor chooses to load just one driver for the entire device (that is, not using the composite device driver) and multiplex all interfaces in software with that driver, the vendor should specify a hardware ID match to prevent the operating system from picking up the lower-ranking match (USB\COMPOSITE).

Vendors should only use Hardware ID matching in their INFs, whether to load a driver or just to provide a friendly device name. Compatible IDs should never be used by vendors in their INFs.

Table 2: Device Identification Strings for the Parent PDO of a Composite Device

If, however, no hardware match is found, Windows Plug and Play makes use of the compatible ID USB\COMPOSITE to load the USB Generic Parent driver. The Generic Parent driver then creates a separate set of PDOs (one for every interface) with a separate set of hardware IDs for each interface of the composite device. The following section displays the format of hardware IDs for child PDOs.

To build the set of hardware IDs for each interfaces PDO, the USBCCGP driver in Windows XP (and Windows Server 2003) and the USBhub driver in Windows 2000 appends the interface number (which is a zero-based hexadecimal value) to the end of the hardware ID.

The class code, subclass code, and protocol code are determined by the bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol fields of the interface descriptor, respectively. These values are in two-digit hexadecimal format.

Vendors should only use hardware ID matching in their INFs, whether to load a driver or just to provide a friendly device name. Items that are not identified in bold in Table 3 should not be used by vendors in their INFs.

Table 3: Device Identification Strings for the Child PDO of a Composite Device

Device Identification Strings for HID Devices

Once the USB stack has identified that the USB device has a HID interface, the HID software stack is loaded on that interface. The HID stack is then responsible for the next phase of the enumeration process. The HID class driver enumerates all the top-level collections and creates a PDO for each collection.

Microsoft defines a top-level collection as a HID collection that is not nested within another collection. In particular, a top-level collection does not have to be an Application collection, as defined in the USB HID Specification.

The examples in the following sections show two scenarios:

• A single top-level collection on the HID interface

• Multiple top-level collections on the HID interface

Example 3: Single Top-Level Collection on a HID Interface

HIDClass creates the hardware IDs shown in Table 4 for a single top-level HID device or interface. Note that if the device is a composite USB device, the interface number is also included in the device identification string.

Table 4: Hardware Identification Strings for a single-TLC HID

Vendors should only use the first two hardware IDs from Table 4 while matching in their INFs (whether to load a driver or just to provide a friendly device name). Items that are not identified in bold in Table 4 should not be used by vendors in their INFs.

Example 4: Multiple Top-Level Collections on a HID Interface

HIDClass creates the hardware IDs listed in the following table for each top-level collection on the HID interface. Note that if the device is a composite USB device, the interface number is also included in the device identification string.

Table 5: Hardware Identification Strings for a Multi-TLC HID

Vendors should only use the first two hardware IDs from Table 5 in their INFs (whether to load a driver or just to provide a friendly device name). Items that are not identified in bold in Table 5 should not be used by vendors in their INFs.

Special Top-Level Collections (Reserved for OS use)

Certain HID top-level collections generate a special HID device string. In Windows 2000, Windows XP, and Windows Server 2003, the top-level collections listed in Table 6 are special cased and each has an additional hardware ID. Table 6 identifies these collections. The last column identifies the additional string that is added to the hardware ID list.

Table 6: Special-Cased Top-Level Collections

Note that "HID_DEVICE_SYSTEM_MOUSE" and "HID_DEVICE_SYSTEM_KEYBOARD" are opened by the operating system listed above in exclusive mode, while all other collections are opened as shared or raw. This is to ensure that keyboard and mouse (pen) input are treated as secure input.

Important: These IDs are explicitly used by Windows to provide default operating system functionality for these classes of devices and must never be used by HID vendors. For a list of drivers loaded for these hardware IDs, see the Windows Driver Development Kit.

 Top of page

References for HID

USB Human Interface Devices, Revision 1.11:
http://www.usb.org/developers/devclass_docs/HID1_11.pdf 

For information about input devices and their interaction with Windows XP:

• "Input Devices" in the Windows XP Driver Development Kit (DDK), available from MSDN and on the web:
  http://www.microsoft.com/whdc/devtools/ddk/default.mspx

• Resources and white papers related to Windows support for input, HID, and smart card devices:
  Input / HID Technologies

• Windows driver setup white papers:
  Setup/Driver Installation
  How to Install Windows Drivers with Software Applications

 Top of page