| Introduction | |
| Descriptor Changes/Additions | |
| Windows Operating System Support | |
| Windows Logo Program Issues | |
| Device Descriptor Example | |
| Call to Action and Resources |
This paper discusses the USB 2.0 Engineering Change Notification for the Interface Association Descriptor (IAD). The IAD can now be used to identify two or more consecutive interfaces, and alternate settings, within one function.
This paper also identifies the operating systems that support the IAD, provides a sample set of IAD descriptors showing supported configurations, and lists current IAD guidelines for independent hardware vendors (IHVs) and original equipment manufacturers (OEMs).
The Windows 98 operating system was the first client operating system to provide native Universal Serial Bus (USB) support. Windows 98 follows a rule that each interface of a multi-function, composite device should load its own function driver. This rule was created because the USB specification did not provide specific framework support for multiple interfaces within one function. However, several USB device classes, defined by the USB Device Working Group (DWG), have expressed the need for multiple interfaces to be grouped to create a single function, as well as an intern created class-specific protocol for merging interfaces together.
The recent USB 2.0 Interface Association Descriptor (IAD) Engineering Change Notification (ECN) introduced a new standard method in the USB device framework for describing grouping of interfaces (and their alternate settings) within a function. The IAD can now be used to identify two or more consecutive interfaces and alternate settings within one function.
This section discusses new Interface Association Descriptor (IAD) descriptor features and the changes that are required in the Microsoft Windows family of operating systems to support IAD.
The IAD device must not use the class/subclass/protocol (C/S/P) as 0x00 respectively, in the device descriptor. Instead, the USB core team has allocated a device-level class code set that must be included with device implementations that use the IAD. This code provides the easiest detection of IAD-enabled devices during device enumeration. Additionally, the code allows the installation of a special-purpose bus driver that correctly enumerates the device on legacy operating systems that do not support IAD.
The following device descriptor example highlights the C/S/P codes and the associated values that must be used for a USB device that supports IAD.
DEVICE DESCRIPTOR:
BYTE bLength: 0x12
BYTE bDescriptorType: 0x01
WORD bcdUSB: 0x0200
BYTE bDeviceClass: 0xEF
BYTE bDeviceSubClass: 0x02
BYTE bDeviceProtocol: 0x01
BYTE bMaxPacketSize0: 0x40
WORD idVendor: 0x045E
WORD idProduct: 0xFFFF
WORD bcdDevice: 0x0100
BYTE iManufacturer: 0x01
WORD iProduct: 0x02
WORD iSerialNumber: 0x03
BYTE bNumConfigurations: 0x01Caution
Devices that use the IAD but do not set the device descriptor’s C/S/P code to the new, required class code set may still load the composite device driver on legacy operating systems. However, the device may not work correctly.
The Interface Association Descriptor (IAD) is used to identify two or more consecutive interfaces (and alternate settings) that need to be grouped within one function. To review the IAD structure, go to http://www.usb.org/developers/docs/InterfaceAssociationDescriptor_ecn.pdf
.
See "Device Descriptor Example" later in this paper for an illustration of a USB device that supports a set of interfaces that are grouped into a single function using one IAD.
Note: A device can have more than one IAD embedded within the configuration descriptor set. The IAD must reside immediately prior to the first interface in the interface group structure.
If the USB device class specification contains values for the bFunctionClass, bFunctionSubclassClass, and bFunctionProtocol fields, then they must be used in the IAD. If they are not defined in the USB class specification, the bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol fields from the bFirstInterface device descriptor must be used in the IAD.
Caution
The IAD descriptor will not
be visible to a function driver. For information on how the fields in IAD are exposed to vendors, see "USBCCGP Changes" later in this paper.
Microsoft is currently working with IHVs to develop devices that support IAD. A beta version of USBCCGP.sys that supports IAD is currently available for testing on Windows XP (SP1) systems.
Microsoft will support IAD in the Windows Vista operating system. Windows XP (SP2) might support IAD.
To avoid compatibility concerns, you should work closely with your Windows liaison to ensure that IAD is implemented correctly in your device. Microsoft considers IAD to be most applicable to composite devices that contain the following device classes:
| • | USB Video Class Specification (Class Code – 0x0E) |
| • | USB Audio Class Specification (Class Code – 0x01) |
| • | USB Bluetooth Class Specification (Class Code – 0xE0) |
Currently, the USB HUB driver creates a compatible ID called "USB\COMPOSITE" if the USB device has multiple interfaces, and the C/S/P codes in the device descriptor are 0x00/0x00/0x00 respectively.
Since the USB-IF Core team has created a new device descriptor C/S/P code set for IAD devices, the USB HUB driver needs to be updated. The updated USB HUB that supports IAD will also create the "USB\COMPOSITE" compatible ID, if the USB device has multiple interfaces and the C/S/P codes in the device descriptor are 0xEF/0x02/0x01 respectively.
Windows operating systems that do not support IAD will not create the "USB\COMPOSITE" compatible ID for a device with IAD descriptors (see "ww" in "Method 1: Interface Association Descriptor," later in this paper). It is an exercise for the IHV to create a USB device driver (also known as a bus enumerator) to emulate IAD functionality.
In Windows XP and later operating systems, Microsoft includes a generic parent driver (USBCCGP.sys) for composite devices. This composite device driver is a bus enumerator that creates hardware IDs, compatible IDs, and a physical device object (PDO) for each interface. With the addition of IAD, each child PDO can contain one or more interfaces.
The following methods are used, in order of decreasing priority, to group interfaces into functions.
If the USB configuration descriptor set contains one or more IADs, the information in them will be used to group interfaces into children of the USB Generic Parent driver. Each PDO, created by the USB Generic Parent driver, contains the number of consecutive interfaces described by the IAD.
The device objects contain hardware IDs and compatible IDs in the format shown in Table 1.
Table 1. Hardware IDs generated by USBCCGP for an IAD device
| Hardware IDs | Compatible IDs |
USB\Vid_xxxx&Pid_yyyy&Rev_zzzz&MI_ww | USB\Class_aa&SubClass_bb&Prot_cc |
USB\Vid_xxxx&Pid_yyyy&MI_ww | USB\Class_aa&SubClass_bb |
| USB\Class_aa |
In Table 1:
| • | xxxx, yyyy, zzzz are extracted from respective device descriptor fields. |
| • | ww is taken from the bFirstInterface field in the IAD. |
| • | aa, bb, and cc, are taken from the bFunctionClass, bFunctionSubClass, and bFunctionProtocol fields in the IAD. |
| • | The device descriptor’s iProduct field that is returned to the client driver as a result of a GET_DESCRIPTOR request, contains the string index used to represent the PDO (also known as the iFunction from the IAD) if it is non-zero. |
For device functions that include only one interface, aa, bb, and cc in Table 1 are extracted from the bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol fields in the device descriptor.
Note: IAD support in USBCCGP.sys cannot be used recursively to bind functions of functions. If a device contains a single IAD descriptor, none of the other grouping definitions, created by individual device class specifications (such as USB Audio), will be applied to group functions by the USBCCGP driver.
In this example, a single function is created for multiple (USB Audio) interfaces if the following three conditions are met:
| • | The interface descriptor’s bInterfaceClass field corresponds to the USB audio device class (0x01). |
| • | The two interfaces have identical bInterfaceSubClass fields on their interface descriptors. |
| • | The two interfaces are consecutive. |
All other interfaces on this device that do not match the conditions, will have their own device objects. This grouping of interfaces is only applicable if the device’s USB configuration descriptor does not contain an Interface Association Descriptor.
Note: Method 2 is currently supported in Microsoft Windows 98 Second Edition and later operating systems.
The device objects contain hardware IDs and compatible IDs in the format shown in Table 2.
Table 2. Hardware IDs generated by USBCCGP.sys for AUDIO interfaces
| Hardware IDs | Compatible IDs |
USB\Vid_xxxx&Pid_yyyy&Rev_zzzz&MI_ww | USB\Class_aa&SubClass_bb&Prot_cc |
USB\Vid_xxxx&Pid_yyyy&MI_ww | USB\Class_aa&SubClass_bb |
| USB\Class_aa |
In Table 2:
| • | xxxx, yyyy, zzzz are extracted from respective fields in the device descriptor. |
| • | ww is taken from the bInterfaceNumber field from the first interface descriptor in each function. |
| • | aa, bb, and cc, are taken directly from the bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol fields from the first USB interface descriptor in each function. |
| • | The device descriptor iProduct field, that is returned to the client driver (as a result of a GET_DESCRIPTOR request), contains the string index that is used to represent this PDO if it is non-zero. |
If the device interfaces are not grouped according to Method 1 or 2, the USB generic parent driver will create a single physical device object (PDO) for each interface.
The device objects contain hardware IDs and compatible IDs in the format shown in Table 3.
Table 3. Hardware IDs generated by USBCCGP.sys for standard interfaces.
| Hardware IDs | Compatible IDs |
USB\Vid_xxxx&Pid_yyyy&Rev_zzzz&MI_ww | USB\Class_aa&SubClass_bb&Prot_cc |
USB\Vid_xxxx&Pid_yyyy&MI_ww | USB\Class_aa&SubClass_bb |
| USB\Class_aa |
In Table 3:
| • | xxxx, yyyy, zzzz are extracted from respective fields in the device descriptor. |
| • | ww is taken from the bInterfaceNumber field of the interface descriptor. |
| • | aa, bb, and cc, are taken directly from the interface descriptor’s bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol fields. |
| • | The device descriptor iProduct field is returned to the client driver as a result of a GET_DESCRIPTOR request, and will contain the string index that is used to represent the PDO if non-zero. |
IAD "Designed for Windows" logo requirements will be defined in the Windows Logo Program version 3.0. For more information, go to http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx.
The following example shows a descriptor layout. The example includes two functions:
| • | Function 1--Video Class
| ||||
| • | Function 2--Human Input Device
|
DEVICE DESCRIPTOR:
BYTE bLength: 0x12
BYTE bDescriptorType: 0x01
WORD bcdUSB: 0x0200
BYTE bDeviceClass: 0xEF
BYTE bDeviceSubClass: 0x02
BYTE bDeviceProtocol: 0x01
BYTE bMaxPacketSize0: 0x40
WORD idVendor: 0x045E
WORD idProduct: 0xFFFF
WORD bcdDevice: 0x0100
BYTE iManufacturer: 0x01
WORD iProduct: 0x02
WORD iSerialNumber: 0x02
BYTE bNumConfigurations: 0x01
-------------------------
CONFIGURATION DESCRIPTOR:
BYTE bLength: 0x09
BYTE bDescriptorType: 0x02
WORD wTotalLength: 0x....
BYTE bNumInterface: 0x03
BYTE bConfigurationValue: 0x01
BYTE iConfiguration: 0x01
BYTE bmAttributes: 0x80 (BUS Powered)
BYTE bMaxPower: 0x19 (50 mA)
-------------------------
INTERFACE ASSOCIATION DESCRIPTOR:
BYTE bLength: 0x08
BYTE bDescriptorType: 0x0B
BYTE bFirstInterface: 0x00
BYTE bInterfaceCount: 0x02
BYTE bFunctionClass: 0x0E
BYTE bFunctionSubClass: 0x03
BYTE bFunctionProtocol: 0x00
BYTE iFunction: 0x04
-------------------------
INTERFACE DESCRIPTOR (VIDEO CONTROL):
BYTE bLength: 0x09
BYTE bDescriptorType: 0x04
BYTE bInterfaceNumber: 0x00
BYTE bAlternateSetting: 0x00
BYTE bNumEndpoints: 0x01
BYTE bInterfaceClass: 0x0E
BYTE bInterfaceSubClass: 0x01
BYTE bInterfaceProtocol: 0x00
BYTE iInterface: 0x05
-------------------------
CLASS SPECIFIC DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------
ENDPOINT DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------
INTERFACE DESCRIPTOR (VIDEO STREAMING):
BYTE bLength: 0x09
BYTE bDescriptorType: 0x04
BYTE bInterfaceNumber: 0x01
BYTE bAlternateSetting: 0x00
BYTE bNumEndpoints: 0x01
BYTE bInterfaceClass: 0x0E
BYTE bInterfaceSubClass: 0x02
BYTE bInterfaceProtocol: 0x00
BYTE iInterface: 0x06
-------------------------
CLASS SPECIFIC DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------
ENDPOINT DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------
INTERFACE DESCRIPTOR (HUMAN INPUT DEVICES):
BYTE bLength: 0x09
BYTE bDescriptorType: 0x04
BYTE bInterfaceNumber: 0x02
BYTE bAlternateSetting: 0x00
BYTE bNumEndpoints: 0x01
BYTE bInterfaceClass: 0x03
BYTE bInterfaceSubClass: 0x01
BYTE bInterfaceProtocol: 0x01
BYTE iInterface: 0x07
-------------------------
CLASS SPECIFIC DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------
ENDPOINT DESCRIPTOR(S):
. . . .
. . . .
. . . .
-------------------------Call to Action
| • | For device manufacturers:
| ||||
| • | For firmware engineers:
| ||||
| • | For driver developers:
| ||||
| • | If you have questions about USB IAD support, contact your Microsoft representative or see the latest Microsoft Windows Driver Development Kit (DDK) USB section. |
Resources
Interface Association Descriptor (IAD) Engineering Change Notification (ECN)
http://www.usb.org/developers/docs/InterfaceAssociationDescriptor_ecn.pdf ![]()
Microsoft Windows Hardware and Driver Developer Information
http://www.microsoft.com/whdc/default.mspx
Microsoft Windows Driver Development Kit
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
Microsoft Windows Logo Program for Hardware, Version 3.0 draft requirements
http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx
Microsoft Windows XP Hardware Compatibility Test Kit
http://www.microsoft.com/whdc/whql/default.mspx