This post has been republished via RSS; it originally appeared at: Microsoft USB Blog articles.
First published on MSDN on May 18, 2010
(This post was temporarily unavailable during some of the recent MSDN Blogs site changes.)
Part of the USB device framework is the ability of a device to expose "configurations," mutually exclusive definitions of what the device can do. Each configuration exposes its own:
· Set of USB interfaces and endpoints,
· Device power requirements, and
· Class- or device-specific information.
If the device has multiple configurations, they can be very similar or very different, but software must choose one of them in order for the device to work. Often we see the first configuration chosen (and by "first" I mean the one defined by the configuration descriptor at index 0). A frequently asked question is: What does it take to influence this choice of configuration value made in software? Let's take a look at each software component.
ü The USB core stack supports devices with multiple configurations. Client drivers can select any of the device's configurations. MSDN reference
· The USBCCGP composite device driver has support for multiple device configurations, with a few caveats. MSDN reference
- USBCCGP will not load on a multi-config device by default because the hub driver doesn't create a "USB\COMPOSITE" PNP ID for a composite device if it has multiple configurations. However, you can write your own INF that matches a device-specific PNP ID to get USBCCGP to load as your device's function driver.
- To select a configuration other than index 0, you must set registry settings as specified in "Selecting the Configuration for a Composite USB Device" . During enumeration, USBCCGP will first attempt to select the configuration whose descriptor is found at the specified "original" index. If the attempt fails, normally due to the configuration requiring more than 100mA while the device's upstream hub has only bus power, then USBCCGP attempts to select the configuration found at the specified "alternate" index instead.
- Drivers that are clients of USBCCGP cannot change the device's configuration value.
· KMDF itself can be used by the device's function driver; however, KMDF's USB I/O Target functionality does not support any device configuration other than the first.
× WinUSB does not support any device configuration other than the first.
· Class drivers often lack support for multiple device configurations. If your device implements a class defined by a USB class specification, please refer to the specification and the relevant Microsoft documentation for a definitive answer.
To sum up, if you are writing your own driver for your device, you can freely choose the device's configuration at runtime, though if you do so you cannot use some of KMDF's USB features. Otherwise, unless your device's class supports multiple configurations, you need to use USBCCGP's selection mechanism, outlined above, to bring multiple configurations into play.
- Philip Ries