Writing Windows WDM Device Drivers

USB_CONFIGURATION_DESCRIPTOR_TYPE	0x02
USB_STRING_DESCRIPTOR_TYPE	0x03
USB_INTERFACE_DESCRIPTOR_TYPE	0x04
USB_ENDPOINT_DESCRIPTOR_TYPE	0x05
USB_POWER_DESCRIPTOR_TYPE	0x06	W98 only
USB_CONFIG_POWER_DESCRIPTOR_TYPE	0x07	W2000 only
USB_INTERFACE_POWER_DESCRIPTOR_TYPE	0x08	W2000 only

Driver Installation

Windows uses values in the Device or Interface descriptors to choose which driver to load. Windows initially forms Hardware IDs using the Device descriptor vendor and product fields (idVendor, idProduct, and bcdDevice). If no installation INF file can be found with a model that matches the Hardware IDs, Windows forms Compatible IDs out of the Interface descriptor class fields (bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol). Windows then searches for an installation file that handles one of these Compatible IDs. If nothing can be found, it prompts the user for a new driver. The chosen installation file specifies the driver to load.

The Interface descriptor class field, bInterfaceClass, is zero for a basic USB device. If the interface meets one of the standard device class specifications, bInterfaceClass is one of the values listed earlier in Table 20.1.

Note that the Device descriptor class fields are not used in the driver selection process. Instead, the bDeviceProtocol field can be used to indicate which, if any, new features are supported, as described in the following text.

USB Classes

As mentioned earlier, the basic USB device framework is enhanced to provide specifications for several different classes of USB device. A Class constant is defined for each device class. Each class may then go on to define various Subclass and Protocol constants to further define the general type of functionality provided in the device.

These class constants are not given in the standard USB device descriptor, but set in the Interface descriptor, instead. If Windows cannot find a driver that matches the Device descriptor Hardware ID, it uses the Interface descriptor class constants to form a Compatible ID.

The USB class specifications define what interfaces and endpoints must appear in a particular class of device. A class may define one or more additional class-specific descriptors for the class device, interface, or endpoint. These devices still provide the standard device, configuration, interface, and endpoint descriptors.

Device classes typically also define a series of class specific request codes for control transactions. Bits 6 and 5 of the request code are set to 01 to indicate that these are class-specific requests. For example, the Hub class request ClearHubFeature has code 0x20.

Obtain the appropriate class specification from the USB website at www.usb.org/developers/. The HID class and its USB implementation are discussed in detail in Chapter 22. The power supply device class is defined purely as a HID device.

The class-specific descriptors are usually types of Interface descriptors. Class-specific descriptor IDs have the top three bits set to 001. Table 20.7 shows the first assigned class-specific descriptor IDs.

Table 20.7 Class-specific descriptor IDs

HID Class	HID descriptor	0x21
	Report descriptor	0x22
	Physical Descriptor	0x23
Communications Class	CS_INTERFACE	0x24
	CS_ENDPOINT	0x25 (not used yet)

Printer Class

As an example of a USB class, it is worth looking here at the printer class. USB printers should resemble FPP or ECP parallel port printers, as defined in the IEEE 1284 specification. The format of the print data sent to the printer is not defined by this spec.

The printer class does not define any class-specific descriptors. The standard device descriptor has zeroes for its class, subclass, and protocol. The standard interface descriptor has constant USB_DEVICE_CLASS_PRINTER (0x07) in its bInterfaceClass field. bInterfaceSubClass is always set to 0x01 indicating a Printer. The bInterfaceProtocol field has 1 if the printer is unidirectional (i.e., it only accept incoming data) or 2 if bidirectional (i.e., it can return status information). A printer can have only one such interface, but it could perhaps switch between the two operating modes using an alternate interface setting.

A printer class device always has a Bulk OUT pipe for data sent to the printer. A bidirectional printer also has a Bulk IN pipe. These pipes are used to carry the relevant page control/description information and status.

A printer uses the default control pipe Endpoint 0 for standard USB purposes. However, it is also used for three printer class-specific requests. GET_DEVICE_ID (request 0) reads an IEEE 1284 device ID. GET_PORT_STATUS (1) gets a status byte that mimics the Centronics printer port status. SOFT_RESET (2) flushes all the buffers, resets the Bulk pipes, and clears all stall conditions.

New Features

USB continues to evolve, both to define new classes of devices and to make implementation of these devices easier. The USB Common class specification document firstly defines how new