We are currently writing firmware for a USB superspeed device which is planed to be used by one application only and the idea is to access it through Winusb.
If possible we want to avoid writing (and signing) an .inf file to associate the device with the winusb driver.
A chain of documents apply to what descriptors need to be provided by the device
According to
https://learn.microsoft.com/en-us/previous-versions/dn385747(v=msdn.10)?redirectedfrom=MSDN
a BOS descriptor is now used to declare windows specific functionality, no longer the string index at 0xEE.
Question: Does this mean for the firmware that no special handling of 0xEE string index is required if Windows 10 is the minimum supported target OS?
The Winusb association should be possible by requesting it by means of a corresponding descriptor (code fragment)
// Microsoft OS 2.0 compatible ID descriptor (table 13)
{20, // wLength
3}, // MS_OS_20_FEATURE_COMPATIBLE_ID
“WINUSB”,
“”,
{4+21+1+40<<1,//wLength:
4, // wDescriptorType: MS_OS_20_FEATURE_REG_PROPERTY: 0x04 (Table 9)
7, //wPropertyDataType: REG_MULTI_SZ (Table 15)
21<<1, //wPropertyNameLength:
u"DeviceInterfaceGUIDs", //bPropertyName
…
However: how do we get the device to show up in Windows Device Manager as a custom device under some tree node other then “USB Controller”?
In previous developments we used an .inf file to do exactly this.
How can the same be achieved using device descriptors and is it possible at all?
I read about extended property descriptors to potentially store things like icons and URLs but no pointers on how to add a custom class of devices. All examples I found so far use device class 0xff and subclass 0x00.
Any hints would be welcome!
Best
roland