Hehe… as it turns out, we can now determine compositeness using the PID, which makes things
so much easier. Okey! On to WHQL certifying 
/R
Robert Bielik skrev:
Hehe… as it turns out, we can now determine compositeness using the
PID, which makes things
so much easier.
Turns out that I spoke too soon. Each unit can be in “boot-mode” at which instant they are a non-composite device, and when
the fw has reloaded, they become composite. With same PID 
So I still need to be able to use the driver for both cases…
Thus, having a section in the INF that directs root IDs to CCGP, is that okay-ish ? Or a problem when WHQL gets in the picture?
/R
As long as you pass WLK tests, WHQL shouldn’t have a problem with using
CCGP here. But since CCGP wasn’t intended for single-interface devices,
be sure to test that scenario.
Robert Bielik wrote:
Robert Bielik skrev:
> Hehe… as it turns out, we can now determine compositeness using the
> PID, which makes things
> so much easier.Turns out that I spoke too soon. Each unit can be in “boot-mode” at
which instant they are a non-composite device, and when
the fw has reloaded, they become composite. With same PIDSo I still need to be able to use the driver for both cases…
Thus, having a section in the INF that directs root IDs to CCGP, is that
okay-ish ? Or a problem when WHQL gets in the picture?/R
Philip Ries skrev:
As long as you pass WLK tests, WHQL shouldn’t have a problem with using
CCGP here. But since CCGP wasn’t intended for single-interface devices,
be sure to test that scenario.
Thanks Philip,
It does seems to work fine. However, since I now have the section for root ID in the same INF as the composite
ID, and the class is Media, my “USB Composite Device Driver” ends up under “Sound, video and game controllers”…
Should I break apart the INF into 2, and have class USB in the one with the root ID?
Otherwise it works nicely, I can toggle between composite and non-composite modes, and driver is picked correctly.
Mind you, I set the Group policy for driver ranking so that 3-rd party driver are ranked equally as inbox drivers. Am
I right to assume that the behavior of my testing would be that of when our driver is from Windows Update?
TIA
/R
I’m not a WHQL expert, but my reading of the ranking docs I linked
earlier matches your understanding.
To get the correct device setup classes, I recommend 2 INFs if possible.
Just in case there’s something relying on CCGP’s setup class as well
as something relying on the class of your functions.
Robert Bielik wrote:
Philip Ries skrev:
> As long as you pass WLK tests, WHQL shouldn’t have a problem with
> using CCGP here. But since CCGP wasn’t intended for single-interface
> devices, be sure to test that scenario.Thanks Philip,
It does seems to work fine. However, since I now have the section for
root ID in the same INF as the composite
ID, and the class is Media, my “USB Composite Device Driver” ends up
under “Sound, video and game controllers”…Should I break apart the INF into 2, and have class USB in the one with
the root ID?Otherwise it works nicely, I can toggle between composite and
non-composite modes, and driver is picked correctly.Mind you, I set the Group policy for driver ranking so that 3-rd party
driver are ranked equally as inbox drivers. Am I right to assume that
the behavior of my testing would be that of when our driver is from
Windows Update?TIA
/R
I want to reinforce what Philip is saying, the inf which installs usbccgp should be the usb device class, you don’t know what the different device classes coinstallers will do, esp the media class which definitely does a lot of heavy lifting. You don’t want that for the usbccgp parent node.
d
Philip Ries skrev:
I’m not a WHQL expert, but my reading of the ranking docs I linked
earlier matches your understanding.
One thing though, if I install the driver when device is composite, usbccgp gets installed for the root ID via usb.inf instead of my INF, but
that is not really a problem as it works fine. When device is in non-composite mode, my INF installs usbccgp and it works fine all the same, but this might be a difference in behavior with regard to my INF being on Windows Update?
/R
Doron Holan skrev:
I want to reinforce what Philip is saying, the inf which installs usbccgp should be the usb device class, you don’t know what the different device classes coinstallers will do, esp the media class which definitely does a lot of heavy lifting. You don’t want that for the usbccgp parent node.
Thanks to you both, I broke up INF in two and now the composite device driver ends up in the USB device class. Looks (and probably is) much better
Thnx again,
/R
Robert Bielik skrev:
Philip Ries skrev:
> I’m not a WHQL expert, but my reading of the ranking docs I linked
> earlier matches your understanding.One thing though, if I install the driver when device is composite,
usbccgp gets installed for the root ID via usb.inf instead of my INF, but
that is not really a problem as it works fine. When device is in
non-composite mode, my INF installs usbccgp and it works fine all the
same, but this might be a difference in behavior with regard to my INF
being on Windows Update?
Hmm… forgot to add the INF packages via pnputil. Now my INF is chosen instead of usb.inf
/R