(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
· 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