We have a hardware device that presents as a composite USB device: MSC+CDC+HID+WebUSB. We don't want to support WebUSB for Windows 7 for a variety of reasons, but would like the device to install "successfully" and find drivers for all the USB interfaces it supplies, so that the user doesn't see the Windows notification "Device driver software was not successfully installed".
On Windows 10, support for all devices is already built in. On Windows 7 we supply a driver installer that provides CDC (usbser), and the others are built in. The .inf file for CDC matches the device's USB VID, PID, and a specific MI, e.g. USB\VID_vvvv&PID_pppp&MI_00. The WebUSB device is at USB\VID_vvvv&PID_pppp&MI_04.
I'd like to supply a dummy driver for MI_04 so it installs successfully but does nothing. Is there a built-in dummy driver available in Windows 7, or some way to use some other built-in driver that will do nothing? Or is it easy to build a dummy driver to install for that interface?
I had the wrong search term. I wanted a "null" driver. Link here explains: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/installing-a-null-driver. A null device is recognized but not used and will not be started.
Based on the link above, I added something like this to my .inf:
[Devices]
...
"WebUSB device dummy = NullInstall, USB\VID_vvvv&PID_pppp&MI_04
...
[NullInstall]
; empty
[NullInstall.Services]
AddService = ,2 ; no value for the service name
Related
I created an small embedded WinUSB device which offers 2 bulk endpoints. This device can communicate with Linux and with Windows10 without installing driver, or a .inf file.
Now we want to use the same API with a embedded Linux. The USB-Gadget mode offers Serial CDC/ACM and RNDIS-Ethernet and many more.
I was able to create a USB-Gadget with the gadgetfs which had only bulk ep. I could communicate with Linux and Windows host. The USB-Device had /dev/ttyGS0 to communicate. But in Windows I had to install WinUSB driver manually.
I work with yocto to create embedded kernel.
I added some line of code here: /linux-imx/drivers/usb/gadget/legacy/serial.c , f_serial.c, u_serial.h to add additional variable os_desc and parameter use_winusb. But the resulting g_serial still creates a COM-Port in Windows10 or a no WinUSB device. For our device we need WinUSB-Device only.
The RNDIS Gadget does has WinUSB support. So I tried to create a own USB-Gadget device with https://github.com/libusbgx/libusbgx. But if I use the USBG_F_SERIAL function type then it can't create WinUSB. See error:
Error setting function OS desc
Error: USBG_ERROR_NOT_FOUND : Not found (file or directory removed)
If I use USBG_F_RNDIS, it works, and with manipulated USB descriptor it'll recognized by Windows as WinUSB device. But Linux implement's it as USB-ETH ethernet device. The USB-Device get's no /dev/ttyGS0 serial connection to communicate.
I'm reading the Linux kernel driver source now, to find the position, where I can simply ann this WinUSB os-descriptor stuff into the USBG_F_SERIAL type. But I think it'll take month to get through.
Any solution would be ok. Patch for the Linux driver sources g_serial or how to configure a USB-Gadgetfs would be great. Any hint, where to put additional code would also be fine.
I wanted to change the kernel, but fortunately found this:
https://blog.soutade.fr/post/2016/07/create-your-own-usb-gadget-with-gadgetfs.html
This code made it easy to add WinUSB features.
Source of modified Version for WinUSB: https://github.com/rundekugel/gadgetfsd/tree/WinUSB
I am trying to change the installed driver for a device using SetupAPI. The driver is already present on the PC, just not currently selected.
More specifically, I am trying undo the installation of a third-party driver for a USB composite device, and install the default windows driver instead.
I already got it almost working like this: First, find the device using
SetupDiGetClassDevs
SetupDiEnumDeviceInfo
SetupDiGetDeviceInstanceId
to find the device.
Next, find the default USB composite device driver I want to install using
SetupDiBuildDriverInfoList
SetupDiEnumDriverInfo
SetupDiGetDriverInfoDetail
Once I found the driver, I call
SetupDiSetSelectedDriver
SetupDiInstallDevice
This actually does switch the driver back, as can be observed in device manager.
However, the third party driver put the device into its own group/category, and this change is not undone when using my approach.
Manually selecting the standard USB composite device driver in the device manager does restore the device category back to USB Controllers, which is why I think my driver installation process is incomplete. What might I be missing?
Turns out the working installation sequence is
SetupDiSetSelectedDevice
SetupDiSetSelectedDriver
InstallSelectedDriver // From newdev.dll, not in a public header
How would an OEM go about getting their USB device driver added to Windows Update, so that it will be downloaded and installed automatically when the device is connected to the PC? In our case, if it matters, it will be a custom USB device class, and the driver will wrap WinUSB.
Is it possible to do this for Windows 7, Windows 8, and Windows 10? 32 and 64-bit.
What keywords (for searching) and concepts should I be aware of?
The question is misguided. The interface to WinUSB lives in userspace - not kernel space - so that DLL will be a library that lives in userspace; it won't be a driver.
The device will report via its device descriptors to Windows that it can use the WinUSB driver, so Windows won't look for its wrapper.
I've been asked to help with some problems that a company are having with an Windows installer they have that includes some custom driver installation for some hardware they make.
I've got access to the source code to build the software and installer (which is an WIX/MSI one), but don't have access to the hardware, so can't actually test it properly.
Is it possible (either with a toolkit, or without) to trick windows into thinking that a specific device USB device has been attached to the computer in order to trigger Windows into trying to install the drivers? . I've got access to all the Vendoer Id, DeviceID, etc information.
Thanks
Tom
That should be possible. Take a look at WDK USBSamp and NDIS Virtual miniport (or virtual serial driver) samples. The first one is a USB driver sample and second one demonstrates how to build virtual driver. You should be able to combine the two to create a virtual USB driver.
This may not be considered to be directly programming related but I am at a loss to know where else to ask. I have tried looking at a variety of websites but so far Google has not been my friend.
I am having trouble finding out whether I need to write my own device driver for the various windows/linux/mac platforms that the device I am developing may be connected to, or whether the functionality is provided by the standard drivers.
My device is a USB CDC (communications device) that appears as a COM: port. It also includes a battery charger that will, once the device has been enumerated require the full 5 unit load (500mA) supply current that can be drawn from the USB connector. My problem is that if the USB driver in the host decides that it cannot deliver the full supply current then it should fail to enumerate the device.
If, as a fallback, I provide a second configuration set that only allows the device to draw 1 unit load from the interface connector will the standard drivers enumerate the device using this configuration.
You need to write a .inf file for Windows that ties up your device VID and PID with the system usbser.sys. Mine looks like this (Replace YourCompany as necessary, put in your VID and PID (in hex), and change the DriverVer line to whatever date and version you want):
; -----------------------------------------------------------------------------
; XP/2000 USB Comms Port Setup
; -----------------------------------------------------------------------------
[Version]
DriverVer=12/03/2008,1.0.0000.0000
Signature="$Windows NT$"
Class=Ports
ClassGUID={4d36e978-e325-11ce-bfc1-08002be10318}
Provider=%YourCompany%
[DestinationDirs]
DefaultDestDir=10,system32\drivers
DriverCopyFiles=12
[ControlFlags]
ExcludeFromSelect = *
[Manufacturer]
%YourCOmpany%=YourCompanySerialPort
[YourCompanySerialPort]
%YourCompanyUSBSerialPort%=YOURCOMPANYUSB,USB\VID_1234&PID_ABCD
;
; Win 2000/XP
;
[YOURCOMPANYUSB]
Include=mdmcpq.inf
CopyFiles=FakeModemCopyFileSection
[YOURCOMPANYUSB.HW]
AddReg=YOURCOMPANYUSBAddReg.HW
[YOURCOMPANYUSBAddReg.HW]
HKR,,DevLoader,0,*ntkern
HKR,,NTMPDriver,,"usbser.sys"
[YOURCOMPANYUSB.Services]
AddService=usbser, 0x00000002, FuncDrv_Service_Inst
[FuncDrv_Service_Inst]
DisplayName=%USBFilterString%
ServiceType= 1
StartType = 3
ErrorControl = 0
ServiceBinary = %12%\usbser.sys
[Strings]
YourCompany="YourCompany"
YourCompanySerialPort="Your Company USB Serial Port"
USBFilterString = "USB Serial Service"
Note this works with 32 bit OSs only. It also works with Vista although the file header doesn't say so!
Be aware that some versions of usbser.sys have significant problems, including bluescreening, for example when transferring packets that are exact multiples of 64 bytes. If you're using XP SP2 or previous then install hotfix KB943198. XP SP3 and Vista are fine.
For the Mac you simply need to report your device class correctly and the driver scan picks up the correct drivers. (Windows ignores the device class which is why you need to supply the .inf file).
EDIT: Sorry, I should have been clearer. This will not fail to enumerate if it can't draw the full load - I'm not sure that's possible.
You are correct on the driver question. When the device is plugged in and goes through the enumeration process it is required to stay < 100mA. The host will interrogate and determine the configuration(s). If there are more than one which support different power levels, then the driver will need to decide to select the appropriate configuration. If there is only high-power and it is not available, then it will not enumerate the device. In general, the standard driver doing CDC wouldn't be aware of the different device level configurations that would possible and so would require some degree of customization to handle them.
I am not sure about power question but ther is pleanty CDC drivers (or I think there is) so you could use one. For the power question, the solution with many configuration is probably good one, I have never encountered this in work (I have USB analyzer) but at home sometimes when I have 3 or more different devices that requires power from USB I got failed enumeration. I supose this is operating system choice if it can't supply power to new device it cut's it off (sensible choice as it can't power it). This is my gues rather checking USB standart.
If your device reports a device ID that the host OS already supports,
then they won't need a driver.
You may need to impersonate an existing USB uart. Data sheets are readily available.
(But I figure you already knew that.)
I'm not sure that the host OS will honour your multi-configuration idea.
But give it a punt so we all know!
If your device is connecting as USB CDC-ACM device to the windows desktop host, the windows desktop already provides the driver usbser.sys. But there are some some issues in windows Vista. You just need the inf to install the usbser.sys on desktop. For WinCE you do not have the driver and for you need to write or get one from any third party vendor. Here is one
http://www.em.avant-garde-lab.com/Products.html
If your device specifies itself as self powered in its device descriptor then the host would rely on the devices self power capability. You can check at usb.org for details.
Thanks.