I am prototyping a keyboard using a Pi Zero, and I plan to set the Pi Zero up so that it emulates an HID-compliant USB keyboard (for Windows). There are many guides on how to do this, so I do not think this will be an issue. The additional functionality of this keyboard is going to require the ability to configure certain aspects keyboard on the host machine and send those configurations back up to the device.
My understanding is that once I have the pi zero emulating an HID keyboard, I will not have to do any extra work with Windows to get the host to accept the new keyboard device - it will automatically recognize the HID device and use the correct built-in driver. The configuration bit, however, I will have to work on myself. I was planning on writing a Win32 application that calls WinUSB as the other driver that handles transfer for the configurations.
On the MSDN page for selecting a USB driver model, it states that WinUSB is a good option if:
Your device is accessed by a single application.
The question stands thusly:
Does having my device configured as an HID keyboard prohibit me from being able to use WinUSB as a configuration driver? More specifically, does having my keyboard constantly open in an HID filter driver (I believe the HID host is a filter driver) count as the device being used in one application already, where the configuration application would be a second?
I believe this answers my question.
https://social.msdn.microsoft.com/Forums/en-US/9687e8ba-9eb0-4d41-a8ac-973a029e05b2/winusb-sample-to-read-inputs-from-keyboard
only one driver can be installed on the device, either HID or winusb. you could force winusb onto the keyboard but then it would stop looking like a keyboard to the OS.
Ignoring the irking lack of capitalization in this post, this seems to state pretty conclusively that a separate driver needs to be written. How unfortunate.
Related
I am planning to write driver for USB or Bluetooth multi-touch device similar to Apple Magic Trackpad or Logitech trackpad for Mac.
The idea is that all macOS applications can use this multi-touch device. As the newly introduced DriverKit (or HIDDriverKit) is to be bundled with apps, should I still use IOKit or should I use DriverKit?
Thanks.
DriverKit is built around IOKit - it's just yet another interface to it. So I guess your question really is whether your driver should be implemented as:
A DriverKit System Extension (dext)
A kernel extension (kext)
Something else
You won't escape IOKit either way, because USB devices are only accessible via IOKit, and the HID stack is built on it too.
Bluetooth
As far as I'm aware, there aren't Bluetooth APIs for use with DriverKit, at least not yet. (As of macOS 10.15.4)
So if your device uses a custom Bluetooth protocol which needs to be turned into a HID event source from scratch, then I don't think you'll be able to use DriverKit, at least not exclusively.
If your device already appears to the system as a HID device but your driver needs to rewrite HID reports, then I think it might be possible to implement using DriverKit - at the very least it's worth researching.
Implementing it as a kext will definitely work for all cases, the trouble is any new kexts will have a very limited shelf life at this stage.
USB
For USB, it's more straightforward, there are direct DriverKit USB APIs. USB HID drivers are one of the well-supported scenarios by DriverKit. So you should definitely not use a kext to implement a USB HID driver targeting macOS 10.15+ at this point. In fact, if you did develop a USB HID kext, your users would periodically be presented with an awful warning popup.
"Something Else?"
That brings us to the "something else" category: you may be able to write the driver (almost) entirely in regular user space as a daemon using user space bluetooth and USB APIs, and then inject the HID events produced back into the system. The best way to do this might end up being via a DriverKit driver - so you'd have a user space daemon performing most of the driver logic, and a small DriverKit driver creating a "virtual" HID device which just ferries the events produced by the daemon into the HID stack. If you need to support older OS versions, the responsibility of the dext in this approach could be taken by a kext, with the daemon needing virtually no customisation to run on all OS versions.
If your driver will be doing a lot of complicated processing on the raw input data, this might be the way forward, as implementing such logic in a dext or kext isn't ideal.
To say which approach is best I'd really need to know a lot more about the device (and that might exceed the scope of a Stack Overflow question…).
I'm investigating options available for creating a virtual USB device (say, a keyboard or a mass storage device), so to emulate its function as needed and to allow a userspace app to emulate its insertion/removal at will.
What I am not clear about is how to go about the emulation of insertion/removal. It seems that one option is to emulate a (virtual) USB hub and have it fake the device arrival/departure events (and I would also supply the device driver for my virtual USB device and that's where my device logic will reside).
I know my way around Windows kernel (having written NDIS miniport drivers), not afraid of SoftICE, but USB is not my domain, just starting out with it.
Am I on the right track with the virtual hub approach? If so, is developing virtual hub drivers supported by WDK (it doesn't seem to be)?
Any other options?
--
(Edit) Forgot to mention - I am aware of DSF, but it is not supported on W8.
Am I on the right track with the virtual hub approach?
In short - yes, I was right.
That's how USBIP does it and it's a relatively simple way to go. Also, see this comment by Eugen.
I don't know if you are aware, but Microsoft released to Win10 the UDE (USB device emulation).
In the section Write a UDE client driver they describe exactly what you want.
I need to set up USB communication between a Windows 7 host and a Linux device for data transfer. I was able to compile the Linux kernel on the device to include the Gadget Zero driver in the kernel (not as a loadable module - Linux version 3.0.15). My project has some requirements, which also explains why I chose Gadget Zero:
1) On the Windows 7 host, a kernel mode driver must be used to communicate over the USB connection for sending and receiving bulk data. (speed is not important, not a lot of data at once).
2) On the linux device, no requirements on USB side except send and receive data easily over USB link. The data received will eventually be "unmarshalled" to call functions in another kernel module (and those responses packaged and sent back to the host).
3) Multiple linux devices will be connected to the host, so need easy way to enumerate connected devices and communicate with them.
So due to the requirements, I decided against the Gadget Serial. I'm having serious issues sending and receiving data over the virtual COM port in kernel mode (KMDF) in Win 7 host. WinUSB does not seem to want to open my attached device (I'm using KMDF windows USB driver from template in VS2012) Also, the gadget serial driver on the linux side, I cannot find the functions where the data is received and sent. Plus, any received data on the linux device seems to be echoed back to the host for some reason. (and to test this, I wrote a simple user-mode app in Windows, which is a no-no for my project).
Gadget Zero, it appears much simpler on the linux side. I can plug the USB cable to the Win7 host, and I can get the device to appear in the device manager. However, again I am having problems with getting communication going over the link. Gadget Zero has 2 bulk endpoints, so this shouldn't be an issue. Surely, someone has made data communication possible between a Windows host and a linux device using Gadget Zero? With Gadget Zero, it should be easy to enumerate the connected linux devices and communicate with them.
The trick is to keep the Windows side communication in kernel mode. Can someone point me in the right direction perhaps with Gadget Zero, Windows 7 KMDF, and some sample source code? I have a hard time believing no one has done this before because my internet searches don't turn up much. (and mostly user-mode solutions with Gadget Serial).
Thanks!
So you're writing a Win32 driver in which you want to communicate with your linuxed usb? I haven't written much win32 kernel code, but I believe I've seen a huge section in the doc, saying something like "This is how you make usb drivers"... That'd be it. In other words, when in kernel mode you have access to the full kernel usb layer. You don't need an existing driver or whatnot.
On the linux side you can use the serial gadget, in a different run mode. Only the default run mode, registers it self as VCP. There exist a more basic mode:
modprobe g_serial use_acm=0
Give it your own vendor id and you'll be able to attach your very own custom win32 driver. The 'multiple linux devices' will be handled by Windows. (Multiple instances of your driver, will be initiated.)
The echo you're seeing btw, is most likely a terminal feature. (The terminal mode on uarts will echo.) You have to disable it, when connecting. And now that you're at it, you also have to disable the xon/xoff, esc chars etc. (Standard legacy rubbish.)
And another thing. I'm not sure the gadget zero actually sends the data onto the line. It's meant for testing the gadget framework. (I could be mistaken though.)
Anyway, you've prolly solved this issue years ago. I'd be nice to know what you came up with.
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.
A question to maybe some who have worked extensively with WinUSB APIs or user mode USB drivers - can the WinUSB API or a user mode driver be used as a passive observer of USB connections, capturing notification of interrupts, control requests, data transfers, etc. without interfering with other applications (such as iTunes) which would obviously require concurrent access to the device at the same time my application is monitoring the connection and displaying data on it?
Or do you pretty much have to write a kernel-mode filter driver and inject yourself in the USB stack in order to make that happen?
In the past, there have been a few credible options (libusb-win32 and usbsnoop to be specific) though both are built around the old DDK, not the Windows Driver Foundation, and are not really supported on a regular basis any more. I'm hesitant to build something significant around them, as a result.
You must write a filter driver. There is no other way to intercept traffic generated by other devices. And you can use newer versions of the DDK, that is, KMDF for this task. It will make your life easier. But I think it will be cheaper and more effective just to get a hardware bus analyzer.
There is a good overview by OSR. You must signed in to read this, but I strongly advice to sign in anyway if you are going to do any kernel mode development.
The core USB drivers in Windows 7 have ETW trace points, so you can sniff traffic that way (blog post ETW in the Windows 7 USB core stack), but it is a bit kludgy and has some limitations like only tracing the first 32 bytes of each packet.
I have made a USB filter driver (KMDF) that is pretty easy to use (IMHO): http://code.google.com/p/busdog/
USB Sniffer allows you to display, record and analyze all the data transferred between any USB device connected to your PC and applications. Also you can recover transferred data (for some file types).
The resulted project includes such components: Driver, Common library, GUI.
http://tellmeword.com/5zu2z5