C0 |
The first three items specify the Application collection as being a keyboard in the generic usage page. A client will therefore know straightaway that this device is a keyboard.
The next items define the modifier input controls. There are eight single-bit inputs, each naturally reporting either 0 or 1. These inputs correspond to eight usage values in the keyboard usage page, the left Shi ft key being pressed, onwards.
The next item defines a reserved constant byte of eight single bits. Note how the Global Report Size and Report Count items persist after the previous Main item.
The next control is for the output LEDs. There are five of them, still bits needing values of 0 or 1. The LED usage page is now in force and the output bits correspond to the NumLock key, etc.
The next control is a 3-bit constant field, padding the output report to make it up to a complete byte.
The actual key presses are defined in a single Input item with its 'Array' bit set. Up to 6-key scan codes may be read, each of eight bits. However, the actual values returned are in the range 0 to 101. The keyboard has 102 keys and three modifier keys, returned separately as three bits.
No Report ID items are given, and so the descriptor describes one report that contains the current state of all the input and output items. An actual input report, therefore, always contains the eight modifier bits, a reserved byte of 0x00, and one to six key scan codes padded to six bytes with zeroes. An actual output report just contains one byte with the lower five bits giving the required LED states.
Pressing Ctrl+Alt+Del might result in the six input reports shown in Table 22.9. The reserved byte values are not shown.
Table 22.9 Ctrl+Alt+Del input reports
| Transition | Modifier byte | Scan codes (hex) |
|---|---|---|
| Left Ctrl down | 00000001 | 00, 00, 00, 00, 00, 00 |
| Left Alt down | 00000101 | 00, 00, 00, 00, 00, 00 |
| Del down | 00000101 | 63, 00, 00, 00, 00, 00 |
| Del up | 00000101 | 00, 00, 00, 00, 00, 00 |
| Left Ctrl up | 00000100 | 00, 00, 00, 00, 00, 00 |
| Left Alt up | 00000000 | 00, 00, 00, 00, 00, 00 |
Conclusion
This chapter has introduced you to the Human Input Device (HID) model. A HID device uses various descriptors to define its functionality. The most important of these, the Report descriptor, defines what input reports it generates and the output reports it can receive. The controls within a report are given 'usage' values that define their function exactly. A full example of a Report descriptor was given for a HID keyboard.
The next chapter looks at how to use the HID class drivers in Windows. Both kernel mode drivers and user mode applications can access HID devices.
Chapter 23
HID Clients
This chapter shows how to use the Human Input Device (HID) model in Windows. It is easy to write a user mode application to talk to a HID device through the Windows HID class driver. If need be, you can write a kernel mode HID client to do the same job. A HID kernel mode client can be layered over the HID class driver in the normal way. Alternatively, it can use Plug and Play Notification to find any suitable HID devices. Windows provides routines that make it much easier to analyze HID Report descriptors and send and receive reports.
This chapter initially looks at how to write a user mode application, called
Later, the HidKbd kernel mode HID client driver is described. This illustrates the Plug and Play Notification technique of finding all devices with a matching device interface. HidKbd finds any devices with a HID class driver device interface. If a HID keyboard is found, it makes a device called \.HidKbd available to user mode applications. The
HID Class Driver
The HID class driver is the key to using HID in Windows. It uses HID
When a new HID device is found by the Plug and Play Manager, the installation INF file eventually ensures that the HID class driver and the appropriate minidriver are loaded.
The HID class driver uses the minidriver to read the HID and Report descriptors. The HID class driver then creates a device object for each of the top-level collections described in the Report descriptor. Each device object is registered as belonging to the HID class device interface.
User mode and kernel mode clients can use the HID class device interface GUID to identify all the available HID devices. The client must get the device capabilities to see if the device is of interest. If you were looking for a HID keyboard, you would ignore a HID mouse.
Each request to the HID class driver eventually ends up as a call to the appropriate HID minidriver. Each minidriver knows how to send and receive HID reports, for example. This chapter does not describe how to write minidrivers; this subject is covered in the DDK.
The HID class driver responds to Create, Close, Read, Write, and IOCTL IRPs. Read and Write requests are used for input, output, and feature reports. IOCTLs are used to retrieve HID device capabilities. User mode applications should not use the IOCTLs directly. Instead, various HidD… routines are supplied to make the job easier.
