Hi guys,
My USB device supports up to 8 different interfaces in every possible combination. There can be just one (any of the 8) interfaces enabled at the time, or any number of interfaces in any combination. This creates an .inf file hell, because (to the best of my knowledge) I have to explicitly define PID/MI for each of these combinations and to have different PID for each of them. Otherwise my driver will not be called for “undefined” interface configurations.
I’m sorry if my question is too vague, or makes no sence at all (I’m not a USB expert), but my impression is that the only solution to that problem (multipe interfaces, arbitrarly turned on / off) is to define 256 unique PIDs that will address each possible config. Otherwise, some configs will be not operable.
Are there any other solutions?
TIA,
Vladimir
Vladimir Chtchetkine wrote:
My USB device supports up to 8 different interfaces in every possible
combination. There can be just one (any of the 8) interfaces enabled
at the time, or any number of interfaces in any combination. This
creates an .inf file hell, because (to the best of my knowledge) I
have to explicitly define PID/MI for each of these combinations and
to have different PID for each of them.
First, this isn’t as uncommon as you think 
Second, one way to simplify this greatly, although it technically violates the USB spec, is just to define one PID for your composite configuration, and manually load the generic parent driver for it (write an INF against usbhub/usbccgp). Then fill out the definitions for MI_00, MI_01, etc. based on that one PID. This will guarantee that the generic parent loads, no matter what your descriptors say.
Then, when you enumerate your device, you can just expose whichever interfaces you like, (say, 5, 6, and 8 ;)) and you will get MI_05, MI_06, MI_08 present on your system. But like I said this violates the spec because you don’t have sequentially-numbered, zero-based interfaces.
Otherwise if you want to follow the spec you probably would indeed need to have N PIDs for N configurations (I’m not sure if 256 is correct, the figure you gave… some combinatorics expert can explain.)
xxxxx@gmail.com wrote:
Vladimir Chtchetkine wrote:
> My USB device supports up to 8 different interfaces in every possible
> combination. There can be just one (any of the 8) interfaces enabled
> at the time, or any number of interfaces in any combination. This
> creates an .inf file hell, because (to the best of my knowledge) I
> have to explicitly define PID/MI for each of these combinations and
> to have different PID for each of them.
What will determine which interfaces are live? The interface set has to
be stable by the time you enumerate. Are there DIP switches?
Will a particular interface always use the same driver? What’s the
problem with having your INF file define the 8 PID_xxxx\MI_xx
combinations, loading a driver for each, and then have that driver use
some other criteria to decide whether it should be active or not? You
could, for instance, have the inactive interfaces simply be defined with
no endpoints. The driver could easily check that, and then politely exit.
Otherwise if you want to follow the spec you probably would indeed need to have N PIDs for N configurations (I’m not sure if 256 is correct, the figure you gave… some combinatorics expert can explain.)
It doesn’t take a combinatorics expert. Think of it as a binary
number. Each interface is either enabled (1) or disabled (0). Thus,
each combination can be represented by an 8-bit binary number. Ignoring
the case where no interfaces are enabled, how many different 8-bit
binary numbers are there? Answer: 255.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> the case where no interfaces are enabled, how many different 8-bit
binary numbers are there? Answer: 255.
256 from [0…255] range
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatksih wrote:
> the case where no interfaces are enabled, how many different
> 8-bit binary numbers are there? Answer: 255.
256 from [0…255] range
I find it amazing that, even though you yourself quoted Tim saying “ignoring the case where no interface is enabled,” you go on to fail at refuting him.