Chris Cant - Writing Windows WDM Device Drivers

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.

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

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.

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 class specifications should be written. Then it goes on to describe new features that may be used to extend the basic USB functionality.

Table 20.8 lists the USB extensions. The Shared Endpoint extension is described in the next section.

Support for the USB enhancements is indicated in the device descriptor. The device bDeviceSubClass field is 0x00 and bDeviceProtocol is a bitmap of supported features. Shared endpoint support is indicated in bit 0.

Currently, there seems to be no indication that Windows supports any of these new features [50] The Windows 2000 DDK defines the Interface power descriptor structure. However, it is not apparent whether this information is used by the system USB class drivers. .

Table 20.8 USB new feature summary

Shared Endpoints

Designers of some devices might find that they need many endpoints and pipes, which might require lots of resources. The basic USB standard says that only the default pipe Endpoint 0 can be shared between interfaces.

The Shared Endpoint USB extension allows several logical pipes to be carried on one normal "physical" pipe. Such shared pipes must have the same transfer type (control, interrupt, bulk, or isochronous) and be in the same direction. Each logical pipe defines one or more logical packets for the data it might send.

Hosts and devices that handle shared pipes multiplex the data from each logical source on the physical pipe. For isochronous pipes, the combined maximum data packet size must fit into a frame. The software must ensure that a stall on one logical pipe does halt data flow on another logical pipe.

Flow control can optionally be implemented using a pipe in the opposite direction to data transfer. A source must not send data on a logical pipe until the target has provided a grant to send: a count of the number of logical packets it can receive.

This section briefly discusses options for both device firmware engineers and Windows device driver writers.

The different types of endpoint have different characteristics. Control transfers consist of messages or requests sent when the host dictates. Interrupt, bulk, and isochronous transfers are said to be stream pipes as they keep generating application defined data.