HID software device (emulated) - windows

Do you know any way to make a software (virtual) HID device for Windows and/or Linux?
I want to use some sensors as HID but they don't have any HID so I thought I could have my own HID installed on the PC (the emulated onde) that converts some messages to HID and vice-versa.

Windows doesn't have a way; you will have to simulate mouse and keyboard events instead. Linux has uinput, which will allow you to inject input events directly into the kernel.

Related

Should I use IOKit or DriverKIt (or HIDDriverKit) to write driver for USB or Bluetooth multi-touch device in macOS?

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…).

Can I use WinUSB alongside the built-in HID drivers?

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.

Virtual USB device for Windows?

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.

Virtual HID-keyboard for OS X

I'm trying to create a virtual bluetooth keyboard client for Mac OS. that means my Mac will serve as a BT KB. I read about the bluetooth API in OS X (in ObjC), and I also found an HID API for Mac (in C)
To make this work I understand I need to declare an hid-keyboard-service that should be broadcasted on SDP queries.
if I declare an HID service using the HID API, is my service visible/broadcasted on Bluetooth too? (the documents seems to refer to HID with regards to USB only). - are HID services visible on both bluetooth and USB interfaces, and the underlaying connection is transparent to me?
is there any code that will help me with this you know about? I prefer ObjC, but it seems HID API is C only... :(
Thanks...!
As far as I understand it, a HID device driver represents a device locally to the OS, and by the OS, to various other components. It is not used to "broadcast" on USB nor on Bluetooth. As far as I know, OS X does not include a Bluetooth HID service, and neither does OS X nor the USB chipsets in Macs support USB device mode -- or at least they do not expose it.
You will want to write a Bluetooth service. I have not done that, but the documentation seems extensive. From what I understand, you would somehow have to implement your HID service based on the underlying Bluetooth L2CAP transmission protocol.
Since I have studied neither Bluetooth, nor Bluetooth support under Mac, I am unable to provide any more help. I did take a look at HID protocol specs, and even played with them. HID is relatively trivial to implement, but there will be quite a bit of work on implementing the Bluetooth service first.
It seems similar tools exist for linux and may have usable source code. See this thread for links.

How do I communicate with a GPIO USB device in OS X?

I have a USB web camera from ViMicro that contains a GPIO chip. We have a microswitch wired to one of the IO pins and can read the status of the switch on Windows using an ActiveX control that was provided by ViMicro, named exvmuvc.ax. I need to duplicate this functionality using IOKit on OS X.
USBTrace from SysNucleus displays the conversation happening between the Windows system and the USB device, but I cannot duplicate this on the Mac.
Does anyone know of a software USB sniffer, like USBTrace, that works on OS X so that I can compare the packets? Also, is anyone familiar with this particular camera chip and its GPIO subsystem, even on Linux?
You could use usbtracer from Xcode, or you can try using using USB Prober with a debug release of IOUSBFamily, this will most likely output more information than you actually want. You may want to look at qa1370 for more information.
In general though, I'd recommend you get a hardware USB analyzer, they make this sort of thing much easier.

Resources