Writing Windows WDM Device Drivers

Display	Monitor	USB_DEVICE_CLASS_MONITOR
Physical feedback devices	Force feedback joystick	USB_DEVICE_CLASS_PHYSICAL_INTERFACE
Power	Uninterruptible power supply	USB_DEVICE_CLASS_POWER
Printer		USB_DEVICE_CLASS_PRINTER
Mass storage	Hard drive	USB_DEVICE_CLASS_STORAGE
Hub		USB_DEVICE_CLASS_HUB

Human Input Devices (HID)

One of the USB device classes is for Human Input Devices (HID), described fully in Chapter 22. HID devices do not have to run on the USB, but they fit neatly into the USB device model.

HID provides an abstract model of input devices. A program that uses HID should not care how a device is connected, as long as a suitable HID minidriver is available for the interface. HID hides the implementation details.

Windows includes system HID drivers to interact with USB devices. If a USB device has an interface descriptor that says it is in the HID class, Windows loads the system HID drivers and the USB HID minidriver and reads the HID descriptors. You just need to write a HID client to do something with the device.

The Big Picture

Figure 20.1 shows the logical structure of a USB device. The physical connection of the USB devices does not effect this logical view.

Figure 20.1 USB logical structure

Each device has one or more logical connection points inside it, called endpoints, each assigned one of the following transfer types: control, interrupt, bulk, and isochronous. All devices have an Endpoint 0 for transfers used to configure and control the device.

A connection between the host and a device's endpoint is called a pipe. The connection between the host USB system software and a device's Endpoint 0 is called the Default Pipe.

A device presents an appropriate set of endpoints to the host. A set of related endpoints is called an interface. A device with more than one interface is called a composite device.

Finally, a device may have more than one set of interfaces. Each set is called a configuration. Only one configuration can be active at a time. However, all interfaces (and their end-points) in the current configuration can be active at the same time. Most devices just have one configuration and one interface. Windows prompts you to choose the desired configuration when a device is first inserted.

The host reads various descriptors from a device to find out what configurations, interfaces, and endpoints are available. The host reads these descriptors when the device is first plugged in using the default pipe. Windows tries to set up a kernel device for each configuration or interface found.

Windows USB Driver Interface

The system USB drivers handle most of the hard work of connecting to a USB device. Indeed, some HID USB devices, such as keyboards, mice, and game devices are recognized automatically and do not need extra drivers.

However, most USB devices will need a new driver to talk to the device and respond to kernel or user application requests. At the kernel level, commands are issued by a client driver to the USB system using Internal IOCTLs. The most useful IOCTL allows you to issue USB Request Blocks (URBs) to the system USB driver. URBs let you issue a multitude of function calls to the USB system.

User mode USB utilities can also issue a few ordinary IOCTLs to a USB device, solely to get information about the connected devices.

Before I look at how to write USB device drivers using this USB Driver Interface (USBDI), it is necessary to explore the physical and logical structure of the USB system. The next chapter shows that Windows provides a fairly plain wrapper for the USB logical structure. The main USB concepts are reflected in the interface available to device driver writers.

Transfer Types

At the USB level, a device can communicate in four different transfer types: control transfers, interrupt transfers, bulk transfers, and isochronous transfers. If designing a USB device from scratch, you will have to decide what transfer types are appropriate. As a driver writer, you may simply be told what transfer types to implement. Transfers are always initiated by the PC.

• Control transfers are used by the USB system and clients to send or receive relatively small amounts of data.

• Interrupt transfers signal input events from a device to the PC. Actually, the PC polls the device regularly (every 1ms–255ms) to get any available interrupt data.

• Bulk transfers are used — in either direction — for large amounts of data.

• Isochronous transfers happen regularly and are usually time-sensitive (e.g., for voice data coming from a telephone). USB divides its available bandwidth into frames, each nominally 1ms long. A device can do one isochronous transfer per frame.

The PC USB host juggles the pending transfer requests from various clients so that they fit into the available bandwidth within the frame structure. Isochronous and interrupt transfers can take up a maximum of ninety percent of the available frame bandwidth, leaving some room for control transfers. Most of the available bandwidth in each frame could be taken up by a regular isochronous transfer from one device. In this case, attaching another device that needs isochronous transfers might fail due to lack of bandwidth.

USB Low Level Structure

USB Devices

USB devices can be plugged into any USB ports on a PC. Some USB devices are hubs that allow further USB devices or hubs to be connected. A hub has one upstream connection towards the PC, and multiple downstream ports. Up to 127 devices can be connected in total. A hub counts as a device.

In USB-speak, the PC is called the host. Data is always transferred between the host and a device, or vice versa. Devices never talk to each other. The PC contains the root hub (or hubs), usually with a couple of downstream ports.

This arrangement leads to the star or branch architecture shown in Figure 20.2.

A device that does a useful job is called a function device. A USB compound device supports several functions. Internally, they consist of a hub with several downstream function devices.

Figure 20.2 shows an example USB physical layout. A USB keyboard is connected to one of a PC's USB ports. A USB hub is connected to the other PC port. The hub has two downstream ports. One is spare and the other has a compound USB device connected. Internally, the compound device has a hub and two function devices.

Figure 20.2 Example USB physical architecture