Support for USB Interface Association Descriptor in Windows

Updated: September 16, 2004
On This Page

Introduction Introduction

Descriptor Changes/Additions Descriptor Changes/Additions

Windows Operating System Support Windows Operating System Support

Windows Logo Program Issues Windows Logo Program Issues

Device Descriptor Example Device Descriptor Example

Call to Action and Resources 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).

*

Introduction

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.

Top of pageTop of page

Descriptor Changes/Additions

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.

Device Descriptor

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:   0x01

Caution
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.

Interface Association Descriptor

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 This link leaves the Microsoft.com site.

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.

Top of pageTop of page

Windows Operating System Support

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)

USBHUB Changes

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.

USBCCGP Changes

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.

Method 1: Interface Association Descriptor (IAD)

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 IDsCompatible 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.

Method 2: Special Case for USB Audio

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 IDsCompatible 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.

Method 3: Standard Interface Enumeration (No Grouping)

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 IDsCompatible 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.

Top of pageTop of page

Windows Logo Program Issues

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.

Top of pageTop of page

Device Descriptor Example

The following example shows a descriptor layout. The example includes two functions:

Function 1--Video Class

This function uses the IAD to group interface zero ("0") and interface one ("1").

The Video Class driver stack is loaded through an INF match against the compatible ID that is generated with the method discussed earlier in this paper in "Method 1: Interface Association Descriptor (IAD)."

Function 2--Human Input Device

This function has only one interface (interface two ("2")).

The HID class driver stack is loaded through an INF match against the compatible ID that is generated with the method discussed earlier in this paper in "Method 3: Standard Interface Enumeration (No Grouping)."

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): 
    . . . .
    . . . .
    . . . .
-------------------------
Top of pageTop of page

Call to Action and Resources

Call to Action

For device manufacturers:

Validate that your USB devices enumerate and work properly on operating systems that do and do not support the Interface Association Descriptor (IAD).

For firmware engineers:

Validate that USB devices comply with the IAD specification (version 1.0 or later).

Validate that the USB device descriptor has the new class/subclass/protocol (C/S/P) codes correctly identified.

For driver developers:

Run the latest WHQL verifier tools for all IHV USB drivers.

Ensure that the USB Verifier runs successfully.

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 This link leaves the Microsoft.com site

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


Top of pageTop of page