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.
Related
I am writing the firmware for a USB HID device. When it is connected to a Windows PC (running Windows 8.1, if that makes any difference) it gets listed in Device Manager, under "Human Interface Devices", as "HID-compliant vendor-defined device". For obvious reasons it would be preferable for a nicer description to be shown.
I'd have guessed that the description would be taken from the USB string descriptor table, perhaps from the entry specified in the device descriptor as containing the product name. This doesn't appear to happen. Perhaps there is an error in my descriptors, but when I connect a USB analyser during enumeration it correctly identifies the manufacturer name, product name, and serial number string.
A little googling suggests that the Device Manager's descriptions can be controlled from a driver's .inf file, but this device doesn't have its own drivers.
Am I out of luck, or is there a way for an HID device to determine how it is described by the Device Manager? If there is, what is it?
(Related prior SO question: Rename a USB HID device under Windows. An answer to that question says that you need to write a Windows device driver to do this, but comments on the answer indicate that this shouldn't apply to HID devices, and the answerer concedes this. Unfortunately no further suggestions are to be found there. That question may actually be trying to ask essentially the same thing as I am, but if so it's ill-titled; I am not trying to rename anything.)
I am trying to connect a Bluetooth Low Energy enabled MIDI hardware to wirelessly send data to a Windows PC and get it to detect as a MIDI device in Windows. Currently, the device is able to pair with my Windows 10 laptop and I am able to read the incoming data off of it.
The same hardware is configured and working fine as a wireless MIDI device on Mac and iOS devices(which natively supports MIDI over Bluetooth). I am trying to get this feature implemented on Windows(which doesn't support MIDI over Bluetooth, although it was promised in Windows 10).
The device, when is paired, is showing up in the 'Bluetooth devices' section in device manager, I am trying to make this device showing up as a MIDI device in 'Sound, video and game controllers' section.
Any help/resources somebody can provide to help me crack this problem is highly appreciated.
Following is my current thought process to implement this.
Pair the device and read the data off of it. (Already implemented)
Create a virtual MIDI port. (Don't know how to implement this, I am currently checking out rtpMIDI)
Send the MIDI data which was read from the BLE device to the virtual MIDI port. (Still don't know how to implement this)
Any suggestions/comments on the above thought process as I am absolutely new to Windows Driver Development.
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.
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.