I want to port libUSB driver to the windows driver using WDK (In Kernel Mode).
I found that libUSB internally uses the winUSB ( From libUSB Sources).
This is what I do in the libusb,
I get the handle using, libusb_open_device_with_vid_pid
or libusb internally uses pSetupDiGetClassDevsA and other pSetupDi*** functions
I send the data using libusb_control_transfer or internally WinUSB's WinUsb_WritePipe
What are the equivalent functions of this in WDK in Kernel mode?
Is there any sample that I can use?
NOTE:
The reason I am asking for kernel mode is, I need to take this data and re-route it as HID Mini Driver.
You should read about WDM drivers. It is a totally different story doing this in kernel mode. There is a sample in winddk called usbsamp. I suggest you to start there.
for easier approches, you may want to look at KMDF : read this http://msdn.microsoft.com/en-us/library/windows/hardware/gg463311.aspx
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
So I was wondering: Since libusb provides userspace access to USB, is it possible to port already existing kernel drivers to libusb?
I do understand it might need rewriting of the driver, but do you think it is possible to write a "virtual kernel" that relies on libusb for access to devices and link already existing drivers to that? Essentially writing a layer between libusb and kernel modules that translates kernel USB commands to libusb commands.
Why bother? If you want to run a kernel driver on Android for example, you need to make sure it was compiled for a particular kernel version/device model. So an app will not be able to run on all devices. On the other hand libusb is fully compatible with most of the latest Android devcices.
AFAIK, libusb is a library that communicates with the higher level of the USB layer of the kernel. The lowest parts of the USB subsystem have to be written in kernel space, because they need to have access to the physical address space of the USB host controller and uses interrupts, and other low-level functions that are not possible to implement in user space.
So I don't think that it is possible to port low-level parts of the USB subsystem in user-space.
I have a USB device for which I have an API. This API only works if the USB device doesn't use the ftdi_sio/usbserial drivers.
On my laptop, if I plug the USB device in, these drivers get loaded (as modules) and I have to unload them using modprobe -r after which code using the API can see the device.
I have another device which experiences the same issue although no modules are loaded so I'm guessing these drivers are compiled into the kernel. My question is this - is there any way to stop this device from using these drivers or do I have to recompile the kernel, etc?
Thanks for any help!
You are essentially looking for a way to :
unbind the default driver from your USB device
and
bind a driver of your choice to it.
Take a quick look at this to get you started.
A slightly more detailed description of the same is available in this excellent LWN article of (un)binding device drivers.
I have a USB device that uses the inbox class driver.
How can I write a program to update its FW?
Can I avoid writing a driver by using the WinUSB library?
It doesn't make sense to me that I am using the inbox driver and I will need to write a driver only for the common operation of FW upgrade.
Thanks,
Shai
I have a USB device that uses the inbox class driver.
This class uses HID as base. You could use HID to update the Firmnware too, eliminating the need to provide custom drivers. WinUSB needs at least an inf file.
I have written a application in Qt and what is the best way to communicate with a custom USB device (does not belong to any class - need to write custom drivers for it) under Windows. In Linux I could just share the data with user space from the /dev or /sys filesystems. What are the equivalent alternative in Windows ?
There are a couple of user-space USB libraries for Windows. While Microsoft do provide WinUSB directly, I'd recommend using either libusbx or libusb and installing the driver for your device with zadig.
Using libusbx rather than the Microsoft driver directly has the advantage of being easier to port to other operating systems, which might be a consideration for you as you are using Qt.