Is it possible to match a driver against VID, PID and interface class / interface subclass?
I am developing a driver for a device that is composite device which is using Linux Gadget API. The different functions are midi + vendor specific functionality. In Linux Gadget api different functionality is implemented with function drivers. Some of them are included in Linux and one of them is developed by me. Interface numbers are allocated dynamically so when the function drivers that implement the vendor specific functionality sets the interface numbers we don't know which number this will be. I can set the interface class and subclass freely, and togheter with VID and PID I would be sure that the interface is the one which my driver should take care of... So I am wondering if it is possible to match a driver on vid and pid together with interface class and sublclass.
You want Standard USB Identifiers - Windows drivers | Microsoft Learn
If you need to match against both VID/PID and class/subclass, I don't think you can do that.
Correct. The class/subclass matching is reserved for Microsoft inbox drivers.
The scheme you're describing will not work with Windows. Drivers are assigned based on VID, PID, Serial Number (if present) and Interface Number, and that assignment is cached. Once it has seen that interface 2 is an Audio Class Device, that can't be changed without completely uninstalling.
If you hope to use that hardware in Windows, you will have to insert dummy interfaces in your descriptors.
Are there alternatives? Yes, you could write a driver that claims the entire device (VID_XXXX&PID_XXXX), act as your own bus driver, and create the child hardware identifiers yourself, thereby replacing USBCCGP.SYS. That's not horribly difficult, but it's not trivial, either.
Alternatively, I suppose you could assign different PIDs for your differing interface arrangements.
1 Like
Ok, thanks. I will assign different PIDs to the different interface arrangements.
Do you know what happens if you change the interfacer number, so that for example interface number 2 is no longer an audio class? Will the driver no longer load? Will other interfaces that did not change still be available? Is there any difference in behavior if it is a composite device and some part of the composite device did not change at all?
It's a really ugly situation. Consider how PnP works. Let's say your device presents for the first time, with a UAC audio as interfaces 2 & 3 (audio and video classes always use 2 or more interfaces). There won't be any direct match for the VID/PID/interface, so the system looks at the secondary hardware IDs. One of those secondary IDs using class/subclass identifies you as UAC, and that matches the generic IDs in usbaudio.sys.
As part of that, the system caches your device with the identifier VID_XXXX&PID_XXXX&MI_02. Next time you plug in, there's a direct hit on your device ID.
Now, lets say your device appears with the audio on a different interface. What happens? Well, it depends. If UAC is on interface 0, and there was a previous match on that interface, then the system will load the wrong driver. If UAC is now on interface 3, then it won't find it (because the old interface 3 was subsumed as part of interface 2), so it falls back to the generic class interface, and it probably works.
As I said, it's an ugly world that you probably don't want to explore, although it can be educational to play with it and see what happens.