I wanted to install a driver on a usb device whose vid and pid is not fixed. I cannot include any vid and pid in INF file.
I have already tried DiInstallDriver, but this is not loading the driver for that device.
Also tried with DiInstallDevice but I am unable to get DriverInfoData…
Please provide suggestions on this…
Sorry but that usb device is just wrong. It has to have a fixed vid pid. That is required by the usb spec and has been required since usb was first deployed.
You need to describe your issue in more detail, because that doesn’t make sense. Is this a device that you ship, where customers are allowed to program the descriptors? There is no generic way to handle that. A customer going to that effort is expected to provide their own driver. If that’s not it, then tell us more about your device.
Sorry, I was not very clear in my previous post. Tim, Your understanding is correct.
The USB device PID and VID will be fixed only but it is not known in advance. The VID/PID will be decided by the customers when they program the descriptors. There may be different VID/PID for different devices. The driver needs to support all the devices having different VID/PIDs. We will be able to detect the device as our device using the string descriptors.
Well you are screwed. Also VIDs are registered, your customers shouldn’t just be creating their own. Your customers are going to have to modify the inf file and get that signed.
Consider I have a device with xxxx Vid and xxxx Pid and I have not added this vid and pid in inf file, but I was able to load my driver from device manager manually. Is it possible to load the driver for a device through any application or service even though my inf file is not having the vid and pid of the device
Also VIDs are registered, your customers shouldn’t just be creating their own.
The operative words here being “shouldn’t be” – I can barely describe how hard it was to FIND any USB flash drives that can be customized (you know, that we could have the OSR logo put on them) that had a legit VID/PID in them? It was like a bad joke. VID ABCD, PID 1234 was very common, it turns out.
ANYhow… that’s neither here nor there. Your advice to the OP is correct.
Is it possible to load the driver for a device through any application or service even though my inf file is not having the vid and pid of the device
Well you can add the “Microsoft OS descriptor” to your firmware, this will automatically install the WinUSB driver or other in-box class driver for the device, whatever is its VID/PID. But not your own driver.
Also, there’s something known as “Zadig”…
This is not an uncommon situation. Xilinx and Cypress both ship chips where the VID and PID can be reprogrammed. In that case, the functionality of the device has changed, so the original driver isn’t appropriate. The EASY answer is what Pavel said – use the Microsoft OS descriptors, which can automatically register a GUID that a WinUSB application can fetch. No other driver required. Otherwise, your clients will have to go through the certification process themselves.
Here’s the key question. As a human being, how would YOU decide that a new device was derived from your design? In the information available to you (that is, the descriptors), what makes it unique? If there is nothing unique, then clearly there is no criteria you can use in an INF file to claim them.
In the information available to you (that is, the descriptors), what makes it unique?
Indeed the driver can check the descriptors (for a vendor-specific protocol ID? custom strings?) and for presence of the required endpoints.
Indeed the driver can check the descriptors (for a vendor-specific protocol ID? custom strings?)
That’s too late. The solution has to be at the INF level. If he could get the driver loaded, the problem would be solved.
And, as it turns out, Microsoft does not officially support third-party drivers claiming a USB class code. That doesn’t mean it can’t be done, but I believe INFCHECK fails it so it won’t pass WHQL.
If we look at winusb.inf file, it supports three Windows Compatible IDs. So if you have another kernel driver with valid signature, you can do the same thing to create an inf file to use a different driver and different Compatible IDs.
As Tim mentioned the inf may not be able to pass WHQL (not so sure anyone have tried?), but probably it can pass attestation and then get used by the end customer.
Last time we use libwdi to create an installer to install such an info for libubs0.sys and libusbk.sys and it worked well. I believe it should still work. Take note the .sys driver should have valid digital signature.
So I am thinking the following will do.
package the driver with known VID/PID and submit for attestation signing, this is for existing customers and to get the signed .sys file.
after 1) was done, submit another driver package (with the signed .sys and the inf file for custom Windows Compatible ID) for attestation signing
distribute the second package to those customers who do not want to go through WHQL
@Tim_Roberts said:
And, as it turns out, Microsoft does not officially support third-party drivers claiming a USB class code. That doesn’t mean it can’t be done, but I believe INFCHECK fails it so it won’t pass WHQL.
I belive you here.
We had such discussion in libusb-devel mailing list back in 2012. And in the end, we do not really proceed with the idea of gong with the idea of using MS_COMP_LIBUSBK or MS_COMP_LIBUSB0.
In the end, WinUSB is the way to go for generic USB devices and libusb0.sys is more for legacy devices and libusbk.sys is only for very niche use cases.
But then the
problem is that I am not 100% sure if you can get WHQL for a
class of USB device (no specific VID/PID). It seems to be a
reserved privilege of Microsoft.
@Tim_Roberts said:
Here’s the key question. As a human being, how would YOU decide that a new device was derived from your design? In the information available to you (that is, the descriptors), what makes it unique? If there is nothing unique, then clearly there is no criteria you can use in an INF file to claim them.
Microsoft WinUSB.inf is probably an exception, since Microsoft has reserved privilege.
BTW, libwdi/Zadig was actually one of the primary examples of driver installer for unknow USB VID/PIDs. And it is actually widely used, including Raspberry Pi Foundation. For unknown reasons they actually recommended using libusb0.sys and not WinUSB.
Ref: https://github.com/raspberrypi/picoprobe/issues/15