I have been searching through how to do gamepad and joystick support on Mac for some days and all resources that I found seems to suggest a pre-installed driver along with using Apple's HID API, which works.
The drawback about this approach is that each joystick and gamepad will require another kernel extension to be loaded, so it can be recognized by HID manager, or at least a code less Info.plist saying it conforms to the earlier installed driver. For instance, when I have an 360 Xbox driver KEXT in house, the Xbox controller from Microsoft will work, but not the Logitech one (I tried F710).
As Apple suggests the application that uses a gamepad or joystick should be able to do themselves at user space without introducing any KEXT stuff. Is there a way to do it?
The thing I had in mind was something like using IORegistry or IOUSB API to get the device when they get plugged in (USB Prober shows it at least). Then somehow get the description of the device, then use that description to register the device as a HID one. Then the whole HID manager can be used.
Am I on the right track? Or is there any other way to do this?
Since IOKit API actually provided keywords like kHIDUsage_GD_Joystick, and there's an ForceFeedback.h library, I suppose Apple designed their HID API with joystick and force feedback in mind. That's the slim hope I had that this might work.
Some reference documentation and open source project:
Colin Munro's 360 driver
HID API Documents
DDHID Project
After revisiting this, I found out the solution to be operating directly on the file descriptors of the device. libusb is an excellent library which greatly simplify your life on this and they have Mac supported.
xboxdrv link is a great example on how to operate on file socket using libusb.
In pseudo code, it should look like this:
enumerate device
detect kernel driver and detach it if possible
open device
file off a initial transfer
wait on the callback function to handle msg and error properly
start run loop or select on fd to call libusb_event_handle
Check libusb for more info link.
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 trying to write a custom USB MIDI driver for macOS. I found a few projects online that are based on some old Apple Sample code, one example linked below.
https://github.com/ysalathe/GenericUSBMIDI
The project seems sensible and works to an extent, but I'm having a problem with it. I hoped someone with experience of the macOS CFPlugin based MIDI driver system might be able to help me...
Steps to recreate issue:
Copy the project's product (GenericUSBDriver.plugin) to ~/Library/Audio/MIDI Drivers
Connect my MIDI device via USB
Open Audio MIDI setup and select show MIDI studio
MIDI studio now shows an icon with the name from my MIDI device's USB descriptor. However, my log shows that my driver failed in USBDevice::OpenAndConfigure when USBDeviceOpen() returns kIOReturnExclusiveAccess (USBDevice.cpp line: 189).
require_noerr((*mPluginIntf)->USBDeviceOpen(mPluginIntf), errexit);
Then after clicking 'Rescan MIDI' my driver loads successfully and a 2nd icon appears in MIDI studio with the driver specified name, but the original icon from step 4 persists. So, I now have 2 icons representing the attached device in MIDI Studio.
Googling things like: 'USBDeviceOpen() kIOReturnExclusiveAccess MIDI' gets various 'Apple Mailing Lists' hits around a decade old, but with no solutions.
It seems to me the standard Apple USB MIDI driver is grabbing my device and causing my driver to fail with kIOReturnExclusiveAccess on USBDeviceOpen(). Then after clicking 'Rescan MIDI' the Apple driver has let go, which allows my driver to load.
My device has an asynchronous USB audio interface, and a MIDI interface with 2 bidirectional ports.
My main question is...
How can I get the Apple MIDI system to select my driver after matching on USB VID/PID instead of the standard Apple driver?
but also...
Does anyone know of any docs or books that can help me? Is there a newer/ better way perhaps?
My driver renames the MIDI ports to something more intuitive for our users, macOS seems to ignore the names in the jack descriptors unlike Windows. Is there another way to do this?
I've been reading the book "OS X and iOS Kernel Programming", but while being very interesting hasn't shed any light on this problem. I can get their USB driver example to match on my USB device's MIDI interface and load, but there seems no obvious way for that to then influence the CFPlugin choice.
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.
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.
In Short: I need to detect hotplug events of my USB CDC device by PID/VID and get the corresponding virtual COM port which was created by Windows in Visual C++ and in the end create a dll.
I have a USB CDC device which I need to be notified of when connected/disconnected on Windows. My approach is to use RegisterDeviceNotification and an "invisible" Window to receive WM_DEVICECHANGE notifications. This part is working so far.
Now as far as I found out I need to get the list of USB devices that is plugged, iterate over it and filter out the devices with my PID/VID? I assume that I am then able to get more informations about the device including the COM port?
Is the only way to achieve my goal to use SetupDi calls in setupapi.h? Is using WDK / DDK the only way to achieve my goal?
As soon as that is working I open-source it on http://github.com/vinzenzweber/USBEventHandler. The Mac version is available already!
After digging through tons of useless documentation at msdn and some debugging I found the missing link: SetupDi calls in setupapi.h: More infos as well as source code for Mac and Windows can be found in my USBEventHandler project at github.com with sources for Mac and Windows.