USB组合设备 Interface Association Descriptor (IAD)

USB CDC + HID + IAD interface

The descriptor belove, generated from MCP2200 device board. MCP2200 is programmed PIC18F14k50.
And it look like composite device(IAD, HID +CDC). I have test it by pickit2 programmer.
I know Windows xp sp3 or higher versions needed for IAD devices. 
Anyway, I need smilar descriptor and working PDS project . This descriptor may useful or not. I'm not sure.

1. USB Composite Device

   Connection Status	Device connected
   Current Configuration	1
   Speed	Full
   Device Address	1
   Number Of Open Pipes	5

   Device Descriptor MCP2200 USB Serial Port Emulator

   	bLength	1	12h
   1	bDescriptorType	1	01h	Device
   2	bcdUSB	2	0200h	USB Spec 2.0
   4	bDeviceClass	1	EFh	Miscellaneous
   5	bDeviceSubClass	1	02h	Common Class
   6	bDeviceProtocol	1	01h	Interface Association Descriptor
   7	bMaxPacketSize0	1	08h	8 bytes
   8	idVendor	2	04D8h	Microchip Technology, Inc.
   10	idProduct	2	00DFh
   12	bcdDevice	2	0101h	1.01
   14	iManufacturer	1	01h	"Microchip Technology Inc."
   15	iProduct	1	02h	"MCP2200 USB Serial Port Emulator"
   16	iSerialNumber	1	03h	"0000133170"
   17	bNumConfigurations	1	01h

   Configuration Descriptor 1 Bus Powered, 100 mA

   	bLength	1	09h
   1	bDescriptorType	1	02h	Configuration
   2	wTotalLength	2	006Bh
   4	bNumInterfaces	1	03h
   5	bConfigurationValue	1	01h
   6	iConfiguration	1	00h
   7	bmAttributes	1	80h	Bus Powered
   	4..0: Reserved		...00000
   	5: Remote Wakeup		..0.....	No
   	6: Self Powered		.0......	No, Bus Powered
   	7: Reserved (set to one) (bus-powered for 1.0)		1.......
   8	bMaxPower	1	32h	100 mA

   Interface Association Descriptor Abstract Control Model

   	bLength	1	08h
   1	bDescriptorType	1	0Bh	Interface Association
   2	bFirstInterface	1	00h
   3	bInterfaceCount	1	02h
   4	bFunctionClass	1	02h	CDC Control
   5	bFunctionSubClass	1	02h	Abstract Control Model
   6	bFunctionProtocol	1	01h	AT Commands: V.250 etc
   7	iFunction	1	00h

   Interface Descriptor 0/0 CDC Control, 1 Endpoint

   	bLength	1	09h
   1	bDescriptorType	1	04h	Interface
   2	bInterfaceNumber	1	00h
   3	bAlternateSetting	1	00h
   4	bNumEndpoints	1	01h
   5	bInterfaceClass	1	02h	CDC Control
   6	bInterfaceSubClass	1	02h	Abstract Control Model
   7	bInterfaceProtocol	1	01h	AT Commands: V.250 etc
   8	iInterface	1	00h

   Header Functional Descriptor

   	bFunctionLength	1	05h
   1	bDescriptorType	1	24h	CS Interface
   2	bDescriptorSubtype	1	00h	Header
   3	bcdCDC	2	0110h	1.10

   Abstract Control Management Functional Descriptor

   	bFunctionLength	1	04h
   1	bDescriptorType	1	24h	CS Interface
   2	bDescriptorSubtype	1	02h	Abstract Control Management
   3	bmCapabilities	1	06h
   	7..4: Reserved		0000....
   	3: Connection		....0...
   	2: Send Break		.....1..	Send Break request supported
   	1: Line Coding		......1.	Line Coding requests and Serial State notification supported
   	0: Comm Features		.......0

   Union Functional Descriptor

   	bFunctionLength	1	05h
   1	bDescriptorType	1	24h	CS Interface
   2	bDescriptorSubtype	1	06h	Union
   3	bControlInterface	1	00h
   4	bSubordinateInterface0	1	01h	CDC Data

   Call Management Functional Descriptor

   	bFunctionLength	1	05h
   1	bDescriptorType	1	24h	CS Interface
   2	bDescriptorSubtype	1	01h	Call Management
   3	bmCapabilities	1	00h
   	7..2: Reserved		000000..
   	1: Data Ifc Usage		......0.	Call management only over Comm Ifc
   	0: Call Management		.......0	Does not handle call management itself
   4	bDataInterface	1	01h

   Endpoint Descriptor 82 2 In, Interrupt, 2 ms

   	bLength	1	07h
   1	bDescriptorType	1	05h	Endpoint
   2	bEndpointAddress	1	82h	2 In
   3	bmAttributes	1	03h	Interrupt
   	1..0: Transfer Type		......11	Interrupt
   	7..2: Reserved		000000..
   4	wMaxPacketSize	2	0008h	8 bytes
   6	bInterval	1	02h	2 ms

   Interface Descriptor 1/0 CDC Data, 2 Endpoints

   	bLength	1	09h
   1	bDescriptorType	1	04h	Interface
   2	bInterfaceNumber	1	01h
   3	bAlternateSetting	1	00h
   4	bNumEndpoints	1	02h
   5	bInterfaceClass	1	0Ah	CDC Data
   6	bInterfaceSubClass	1	00h
   7	bInterfaceProtocol	1	00h
   8	iInterface	1	00h

   Endpoint Descriptor 03 3 Out, Bulk, 32 bytes

   	bLength	1	07h
   1	bDescriptorType	1	05h	Endpoint
   2	bEndpointAddress	1	03h	3 Out
   3	bmAttributes	1	02h	Bulk
   	1..0: Transfer Type		......10	Bulk
   	7..2: Reserved		000000..
   4	wMaxPacketSize	2	0020h	32 bytes
   6	bInterval	1	00h

   Endpoint Descriptor 83 3 In, Bulk, 64 bytes

   	bLength	1	07h
   1	bDescriptorType	1	05h	Endpoint
   2	bEndpointAddress	1	83h	3 In
   3	bmAttributes	1	02h	Bulk
   	1..0: Transfer Type		......10	Bulk
   	7..2: Reserved		000000..
   4	wMaxPacketSize	2	0040h	64 bytes
   6	bInterval	1	00h

   Interface Descriptor 2/0 HID, 2 Endpoints

   	bLength	1	09h
   1	bDescriptorType	1	04h	Interface
   2	bInterfaceNumber	1	02h
   3	bAlternateSetting	1	00h
   4	bNumEndpoints	1	02h
   5	bInterfaceClass	1	03h	HID
   6	bInterfaceSubClass	1	00h
   7	bInterfaceProtocol	1	00h
   8	iInterface	1	00h

   HID Descriptor

   	bLength	1	09h
   1	bDescriptorType	1	21h	HID
   2	bcdHID	2	0111h	1.11
   4	bCountryCode	1	00h
   5	bNumDescriptors	1	01h
   6	bDescriptorType	1	22h	Report
   7	wDescriptorLength	2	001Dh	29 bytes

   Endpoint Descriptor 81 1 In, Interrupt, 1 ms

   	bLength	1	07h
   1	bDescriptorType	1	05h	Endpoint
   2	bEndpointAddress	1	81h	1 In
   3	bmAttributes	1	03h	Interrupt
   	1..0: Transfer Type		......11	Interrupt
   	7..2: Reserved		000000..
   4	wMaxPacketSize	2	0010h	16 bytes
   6	bInterval	1	01h	1 ms

   Endpoint Descriptor 01 1 Out, Interrupt, 1 ms

   	bLength	1	07h
   1	bDescriptorType	1	05h	Endpoint
   2	bEndpointAddress	1	01h	1 Out
   3	bmAttributes	1	03h	Interrupt
   	1..0: Transfer Type		......11	Interrupt
   	7..2: Reserved		000000..
   4	wMaxPacketSize	2	0010h	16 bytes
   6	bInterval	1	01h	1 ms

   Interface 2 HID Report Descriptor Vendor-Defined 1

   Usage Page (Vendor-Defined 1)	06 00 FF
   Usage (Vendor-Defined 1)	09 01
   Collection (Application)	A1 01
   Usage Minimum (Vendor-Defined 1)	19 01
   Usage Maximum (Vendor-Defined 16)	29 10
   Logical Minimum (0)	15 00
   Logical Maximum (255)	26 FF 00
   Report Size (8)	75 08
   Report Count (16)	95 10
   Input (Data,Ary,Abs)	81 00
   Usage Minimum (Vendor-Defined 1)	19 01
   Usage Maximum (Vendor-Defined 16)	29 10
   Output (Data,Ary,Abs,NWrp,Lin,Pref,NNul,NVol,Bit)	91 00
   End Collection	C0

 

As I understood from all googling about composite devices, two interfaces usually mean that in Windows device manager

we will see composite device and two other devices that corespond to each interface.

If you need one device, then most likely you will need to use device class 0xEF and USB Interface Association Descriptor,

but I'm not sure if it will do what you need.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff540054(v=vs.85).aspx

http://www.microsoft.com/taiwan/whdc/archive/iad.mspx

usbccgp.sys hangs Windows to death when a descriptor is malformed?

Yes, it's true. Even for full-speed and low-speed devices. So double-check your descriptors:

• The first Configuration Descriptor has ID #1
• The first Interface Descriptor has ID #0 and are contiguous numbered.
  The Interface count in Configuration Descriptor must be set correctly.
• The first Alternate Setting has ID #0 and are contiguous numbered

Problems arise when you change your single-interface USB device into a multi-interface (multi-function) while keeping your USB VID+PID pair!

Even when your change or add some more USB interface with the same VID+PID pair, problems occur.

The Windows behaviour of assigning a driver is as follows:

• If the VID+PID is already known, Windows loads the known driver regardless whether it's a multi-function device or not.
  (I.e. when you loaded a driver before for the non-multifunction device with PnP ID e.g. USB\VID_16C0&PID_06B3, that driver is always used.)
  As a consequence, your driver will fail (typically with a blue screen) when it is surprisingly bound to the - now - multifunction USB device.
  
  
• If VID+PID is not known, Windows tries to load a Class Driver.
  This is "usbccgp.sys" for the top of multifunction devices which is a very special class (not USB\Class_00).
  
  
• Windows remembers the Class-Driver-To-VID+PID(+MI)-binding for the next plug-in event persistently, probably for performance purposes.
  Therefore, when you swap your Interfaces keeping VID+PID, you earn errors.
  But you can get rid easily by uninstalling your device in Device Manager. This will remove the memorized bindings.
  
  
• "usbccgp.sys" itself retries the enumeration process for the child devices in the same way,
  i.e. preferes VID+PID+MI bindings over USB Class bindings.
  
  
• In case of no match, no driver is loaded, and the entry is marked in Device Manager.

So you may conclude:

• VID+PID, and MI numbers (like USB\VID_16C0&PID_06B3&REV_4621&MI_00) have precedence,
  allowing manufacturers to deliver their own multifunction device drivers (replacing "usbccgp.sys")
  
  
• USB CLASS bindings (like USB\Class_07) have less precedence, allowing manufacturers
  to deliver their own specialized device driver replacing one of the system-supplied class drivers (like "usbprint.sys")
  
  
• REV numbers don't matter Windows, so manufacturers are free to (mis)use this entry,
  and there is no option to get more possible USB device bindings "for free" using the REVnumber as an extra binding criterion

An example: 

This INF file snippet is wrong because you have no control whether your driver is bound to the Interface #0
or the entire USB device (except your driver is very smart and can handle this):

• %DevDesc%=Dev,USB\VID_16C0&PID_06B3&REV_4621&MI_00
  %DevDesc%=Dev,USB\VID_16C0&PID_06B3&REV_4620 

(Windows will work as expected most of the time, but users are able to bind multi-function devices to entire devices,
and produce overwhelming trouble with your support.) 

As a result:

If you change your single-interface USB device to multi-interface and vice versa keeping VID+PID,
make sure that you cleaned your Device Manager entries beforehand.
Or at least before you plug your changed device.

Google for devmgr_show_nonpresent_devices and devmgr_show_details to get a clue.

Better you change VID+PID too, providing you have a free pair available.

If you are in doubt offering a single-interface or multi-interface USB device,

simply decide to multi-interface at the first step,

and implement an extra HID or CDC interface to make usbccgp.sys happy.

It's useful for debugging purposes later. At least two childs are needed.

Note that CDC interface (which is itself a composite USB device by design and handled in a special way by usbccgp.sys)

will not run properly in elsewhere-multifunction devices on Windows 2000 and earlier.

USB Composite Device

USB composite device

Examples

USB_CDC_HID_IAD_10.zip

This example implements a composite device of CDC (with IAD) and HID 

The CDC interface is based on the code of USB CDC implementation for 'F32x and 'F34x In either interface, CDC and HID, the device loops back the OUT transfer to IN.

Passed USBCV R1.3.1, the ch9 and HID test
Tested on these Windows version,
- Windows Vista SP1
- WinXP SP3 (usbser.sys: 5.1.2600.5508, usbccgp.sys: 5.1.2600.5512)

On the original WinXP SP2 (usbser.sys, usbccgp.sys: 5.1.2600.2180),
the HID interface of the device works well, but CDC causes BSOD when a test app opens the VCP.

USB_HID_composite_01.zip

This example implements three HID interfaces to SiLabs 'F320/'F340 DK.
Each interface has an interrupt IN EP and an interrupt OUT EP.
The firmware loops back the data sent to the OUT EP to the IN EP, on each interface.

Passed the USB compliance test, USBCV 1.3, ch9 and HID test.
Tested on HClient host app example on WinDDK.

USB_Mouse_INT_01.zip

This is a demonstration which shows a composite device combined SiLabs USB_HID\MouseExample and USB_Interrupt (USB_INT)

• When you are asked a device driver, specify the INF folder attached to this zip file.
• USB_Interrupt host application and device driver works with this implementation without any change.

1. What is composite device

Composite device is defined in the USB spec as follows (usb_20.pdf 5.2.3),
A device that has multiple interfaces controlled independently of each other is referred to as a composite device.
Using composite device, multiple functions are combined into a single device.
Ex.
- Keyboard + Mouse
- Video + USB Hard disk
- I/O device (HID + USB_bulk)

Another advantage of composite device is that it eases the device driver development.
OS assigns a separate device driver to each Interface of the composite device as follows.
Therefore, a dedicated monolithic driver is not required for newly designed device;
you can realize it using existing drivers.

Code:

  +----------------------------+      +----------------------
  | Composite Device           |      | Host PC
  |                            |      |
  |  Function 0 -- Interface 0 --------- Device driver A <--->
  |                            |      |
  |  Function 1 -- Interface 1 --------- Device driver B <--->
  +----------------------------+      +-----------------------

When OS has some required drivers as built-in, they are available for the composite device.

These OS built-in device drivers are called as USB class driver.
Approved Class Specification Documents from USB.org
http://www./developers/devclass_docs#approved

Windows have these built-in class drivers.
USB FAQ: Introductory Level - USB Class Drivers from MS WHDC
http://www.microsoft.com/whdc/system/bus/usb/USBFAQ_intro.mspx

Please note, available drivers for a composite device are not limited only to class drivers.

Any driver can be applied, as long as it doesn't require a device class (class defined in device descriptor).

For example, SiLabs USB_INT and USB_bulk drivers are also applicable for composite devices.

2. How Windows handles a composite device

When a device satisfies these three requirement, Windows system recognizes the device as a composite device.

1. The class field of the device descriptor equals to zero: (bDeviceClass) = (0x00)
2. Single Configuration
3. Multiple Interfaces

[Note]
WinXP SP2, Win2k3 SP1 and Vista supports this alternative requirement.
1'. The class, subclass and protocol fields of the device are that of Interface Association Descriptor:
(bDeviceClass, bDeviceSubClass, bDeviceProtocol) = (0xEF, 0x02, 0x01)

When an USB device is plugged in to a PC, the system reads out the device descriptor of the device and makes these Device ID.

USB\VID_vvvv&PID_pppp
USB\VID_vvvv&PID_pppp&REV_rrrr
(vvvv, pppp, rrrr: four digit hex number for the VID, PID, device release number.
Matches to idVendor/ idProduct/ bcdDevice, defined in the device descriptor)

The system searches device database on the registry, installed by INF files.
When the system finds the Device ID in a device record, it assigns the device driver specified by the record.
However, when it cannot find any matched record, and the device Configuration satisfies above criteria,
the generic composite parent driver is loaded.
This parent driver parses the Configuration of the device, and assigns this Device ID to each Interfaces. 

USB\VID_vvvv&PID_pppp&MI_mm
USB\VID_vvvv&PID_pppp&REV_rrrr&MI_mm
(mm: Interface number of the corresponding function, two digit hex number)

As of the Interface which specifies a class, the system also assigns this Compatible ID.

USB\CLASS_cc
USB\CLASS_cc&SUBCLASS_ss
USB\CLASS_cc&SUBCLASS_ss&PROT_pp
(cc/ ss / pp: two digits hex number. bInterfaceClass/ bInterfaceSubClass/ bInterfaceProtocol, from the Interface descriptor)

The system searches these Device ID and Compatible ID in the device database again.
When it finds a matched record, it assigns the specified device driver to the Interface.
However, when it cannot find any matched record, it shows 'New Hardware Wizard' to users and asks them to install the device driver.

Enumeration of the Composite Parent Device from MSDN
http://msdn2.microsoft.com/en-us/library/aa476434.aspx

3. Implementation

On USB application, firmware, device driver and host application are closely related.
It is desirable to make separate prototypes of firmwares and host applications for each Interface first.
After confirming them to work properly, combine them together.

3.1 Device firmware

When the source code is well organized, modification of the firmware is easy.
Based on one of the prototypes, copy a part of code from other prototypes and insert it to corresponding part of the base source code.
In other word, the source codes should be organized considering to make it a composite device.
When these parameters are defined by #define macro or enum instead of direct number in each prototype,
the combination of prototypes is done smoothly.

• Interface number
• Endpoint address
• Endpoint status (IDLE / HALT)

3.1.1 Descriptors

3.1.1.1 Device descriptor

• bDeviceClass: Must be assigned to zero
• idVendor, idProduct: VID/PID must be unique, to avoid conflict to other devices.

3.1.1.2 Configuration descriptor

• wTotalLength: The total number of bytes of Configuration set, includes all of Interface sets
• bNumInterfaces: Number of Interfaces included in this Configuration

Configuration set means these descriptors, for example.

Configuration descriptor
- Interface descriptor (0)
- - accessory descriptor, such as HID class descriptor, if any
- - Endpoint descriptors
- Interface descriptor (1)
- - accessory descriptor, such as HID class descriptor, if any
- - Endpoint descriptors

HID report descriptor and String descriptors are not included in the Configuration set.

3.1.1.3 Interface descriptors

• bInterfaceNumber: Index of Interfaces, starting from zero
• bInterfaceClass: Specify class code for this Interface

If any specific class code is not assigned to the Interface, set bInterfaceClass to 0xFF (Vendor specific). 0x00 (Reserved) would work, but 0xFF is better.

3.1.1.4 Endpoint descriptors

• bEndpointAddress: must be unique on each Endpoint descriptor

Any duplicated Endpoint across Interfaces is not allowed in a composite device.

3.1.2 Standard requests

3.1.2.1 Additional Descriptor handling
Get_Descriptor must support additional descriptors asked by the host.

• Configuration descriptor: return full Configuration set (see 3.1.1.2)
• Class-specific descriptors:

When the descriptor type in request (MSB of wValue) is not Device(1), Configuration(2) or String(3),
the request may be for class-specific descriptor (in full-speed devices).
In this case, wIndex field of the Setup data shows the Interface number in question.
According to the class specified by the Interface (wIndex),
Get_Descriptor must return the class-specific descriptor specified by the MSB of wValue.
When the class supports Set_Descriptor request, it must be handled similarly to Get_Descriptor.
Interface and Endpoint descriptors cannot be directly accessed with Get_Descriptor or Set_Descriptor.
Therefore, Get_Descriptor and Set_Descriptor have no need to support them.

3.1.2.2 Additional Interfaces handling
wIndex field of the Setup data shows the Interface number in question.
When this Interface number matches to the additional Interfaces, handle the requests as follows.

• Get_Status: return Zero
• Get_Interface: return current alternate Interface number
• Set_Interface: set current alternate Interface to one specified by the request

When the Interface in question doesn't have any alternate Interface, Get_Interface returns Zero.
And Set_Interface succeeds when the wValue is Zero, otherwise return STALL.

3.1.2.3 Additional Endpoints handling

• Get_Status: return HALT condition of the Endpoint
• Clear_Feature: recover the Endpoint from HALT
• Set_Feature: set the Endpoint to HALT
• Set_Configuration: Setup additional Endpoints

When Get_Status, Clear_Feature and Set_Feature are issued to an Endpoint, wIndex field of the Setup data indicates the Endpoint address.
When the Interfaces doesn't have any alternate Interface, set up the Endpoints in Set_Configuration request.
As of the Interface with any alternate Interface, set up the Endpoints belonging to the Interface in Set_Interface.

3.1.3 Class-specific requests

wIndex field of the Setup data of the request indicates the Interface to which this request is issued.
Therefore, dispatch the request by wIndex first, and copy the each handler for class-specific requests from the prototypes under each case.

3.1.4 Endpoint handling

When the Endpoint address and Endpoint status are defined by macro,
modification on this part finishes by copying the Endpoint handler of each prototype to the base one.

3.2 Device driver and host application

OS built-in class drivers are designed to work with composite devices.
In most case, these drivers are applicable to composite devices without any change of default INF file.
However, device drivers provided by vendors are not always designed to work with composite devices.
INF file and host application code should be modified for these drivers.
The device driver itself should work without any change.
Of course, rare exception may exist.

3.2.1 INF file

When the device driver requires an INF file even for single use, the INF file is required as a part of composite device.
The INF file defines the Device ID as follows.

USB\VID_vvvv&PID_pppp
USB\VID_vvvv&PID_pppp&REV_rrrr

For a composite device, the Interface number must be added to this Device ID.

USB\VID_vvvv&PID_pppp&MI_mm
USB\VID_vvvv&PID_pppp&REV_rrrr&MI_mm

For example, when you add the USB_Bulk function (Interface with bulk IN/OUT Endpoints)
to your composite device as the Interface number 1, the Device ID in the INF file (SilabsBulk.inf) is modified as follows.

USB\VID_vvvv&PID_pppp&MI_01
(vvvv, pppp: VID/PID must be unique)

3.2.2 Endpoint address and pipe name / device path name

When two or more devices are combined into a single composite device,
the Endpoint addresses must be often changed to fit to the newly designed device.
Usually, the pipe name and device path name from device drivers are designed to hide the Endpoint address.
Therefore, in most case, Endpoint address reassignment doesn't affect to the host application.

However, there are some drivers which expose the Endpoint address directly to the pipe name.
For these drivers, the host application must be modified to reflect the Endpoint address assignment.
Confirmation for this point is desirable before planning a new device.

• OS built-in class drivers hide Endpoint address behind its device path name.
• MS WinDDK bulkusb and isousb example driver hide Endpoint address behind the pipe name (a part of device path name).
• SiLabs USB_INT and USB_Bulk device drivers hide it behind the pipe name (a part of device path name).
• Cypress ezusb.sys driver hides Endpoint address behind its pipe number.
• Cypress CyUSB.sys driver exposes Endpoint address directly.
  But when the code follows the example of CCyUSBDevice::BulkInEndPt in CyAPI.chm,
  the Endpoint address is hidden behind the index of the Endpoint array.

When a device applies the same class to multiple Interfaces, the host application should be modified to distinguish these Interfaces. 

Enumeration of USB Composite Devices

When a new USB device is connected to a host machine, the USB bus driver creates a physical device object (PDO) 

for the device and generates a PnP event to report the new PDO.
The operating system then queries the bus driver for the hardware IDs associated with the PDO.

For all USB devices, the USB bus driver reports a device ID with the following format:

USB\VID_xxxx&PID_yyyy

Note  xxxx and yyyy are taken directly from idVendor and idProduct fields of the device descriptor, respectively.

The bus driver also reports a compatible identifier (ID) of USB\COMPOSITE, if the device meets the following requirements:

• The device class field of the device descriptor (bDeviceClass) must contain a value of zero,
  or the class (bDeviceClass), subclass (bDeviceSubClass), and protocol (bDeviceProtocol) fields
  of the device descriptor must have the values 0xEF, 0x02 and 0x01 respectively,
  as explained in USB Interface Association Descriptor.

• The device must have multiple interfaces.

• The device must have a single configuration.

The bus driver also checks the device class (bDeviceClass), subclass (bDeviceSubClass), and protocol (bDeviceProtocol) fields of the device descriptor.

If these fields are zero, the device is a composite device, and the bus driver reports an extra compatible identifier (ID) of USB\COMPOSITE for the PDO.

After retrieving the hardware and compatible IDs for the new PDO, the operating system searches the INF files.

If one of the INF files contains a match for the device ID, Windows loads the driver that is indicated by that INF file
and the generic parent driver does not come into play.

If no INF file contains the device ID, and the PDO has a compatible ID, Windows searches for the compatible ID.

This produces a match in Usb.inf and causes the operating system to load the USB Generic Parent Driver (Usbccgp.sys).

If you want the generic parent driver to manage your device, but your device does not have the characteristics necessary
to ensure that the system will generate a compatible ID of USB\COMPOSITE,
you will have to provide an INF file that loads the generic parent driver.

The INF file should contain a needs/includes section that references Usb.inf.

If your composite device has multiple configurations, the INF file you provide must specify which configuration the generic parent should use in the registry.

The necessary registry keys are described in Configuring Usbccgp.sys to Select a Non-Default USB Configuration.

 

USB Generic Parent Driver (Usbccgp.sys)

 This section describes the Usbccgp.sys driver provided by Microsoft for composite devices.

Many USB devices expose multiple USB interfaces.

In USB terminology, these devices are called composite devices.

Microsoft Windows 2000 and Windows 98 operating systems include a generic parent facility in the USB bus driver

(Usbhub.sys) that exposes each interface of the composite device as a separate device.

In Microsoft Windows XP and Windows Me, this facility is streamlined and improved by transferring it

to an independent driver called the USB generic parent driver(Usbccgp.sys).

Using the features of the generic parent driver, device vendors can make selective use of Microsoft-supplied driver support for some interfaces.

The interfaces of some composite device operate independently.

For example, a composite USB keyboard with power buttons might have one interface for the keyboard

and another interface for the power buttons.

The USB generic parent driver enumerates each of these interfaces as a separate device.

The operating system loads the Microsoft-supplied keyboard driver to manage the keyboard interface, a

nd the Microsoft-supplied power keys driver to manage the power keys interface.

If the composite device has an interface that is not supported by native Windows drivers,

the vendor of the device should provide a driver for the interfaces and an INF file.

The INF file should have an INF DDInstall section that matches the device ID of interface. T

he INF file must not match the device ID for the composite device itself, because this prevents the generic parent driver from loading.

For an explanation of how the operating system loads the USB generic parent driver, see

Enumeration of USB Composite Devices.

Some devices group interfaces into interface collections that work together to perform a particular function.

When interfaces are grouped in interface collections, the generic parent driver treats each collection,

rather than each individual interfaces, as a device.

For more information on how the generic parent driver manages interface collections,

see Enumeration of Interface Collections on USB Composite Devices.

After the operating system loads the client drivers for the interfaces of a composite device,

the generic parent driver multiplexes the data flow from the client drivers,

combining these separate interactions into a single data stream for the composite device.

The generic parent is power policy owner for the entire composite device and all of its interfaces.

It also manages synchronization and PnP requests.

The generic parent driver can simplify the task for vendors of composite hardware,

if Microsoft-supplied drivers support some interfaces but not others.

Vendors of such devices need only supply drivers for the unsupported interfaces,

because the generic parent driver facilitates the use of Microsoft-supplied drivers for the supported interfaces.

The following sections describe the features and functions of the generic parent driver:

Enumeration of USB Composite Devices

Descriptors on USB Composite Devices

Enumeration of Interfaces on USB Composite Devices

Enumeration of Interface Collections on USB Composite Devices

Content Security Features in Usbccgp.sys