My Application wants to access a HID device I plugged in, but claiming the device does not
work because its already claimed by IOHIDDevice Driver.
In order to prevent that I learned, that I should create and install a codeless kext driver
for mac(OSX 10.8.2) to blackbox my device from beeing loaded.
I spent two days already and I did not have any success so far.
In my testcase you can find
Log from the USB prober
My codeless kext module
output from ioreg when my device is attached
It seems i cannot attach a file here.
please download it from http://www.guenther-sohler.net/testcase.tar.gz
Depending on what level of access you require, HIDAPI http://www.signal11.us/oss/hidapi/ may provide you with what you need. It's a library that uses IOHidManager as a backend on OSX. Works for me on OSX 10.7.5, no dummy driver required.
Check into a code less KEXT to declare your device as available to user space apps.
It is essentially a plist.
For Yosemite and Mavericks, it needs to be signed by an Apple Developer ID approved for KEXT - you need to be a Developer and apply for that.
Related
I have a DriverKit extension that can match a usb audio device just fine, but if I leave the device plugged in during a reboot, the AppleUSBAudio kernel extension matches it instead.
Unplugging and replugging load my dext instead.
Is this to be expected? Do all System Extensions have this shortcoming? How can I remedy this?
On macOS 11, if one of Apple's kexts matches your device, and their driver is in the "boot" or "sys" collections (see man kmutil), which it normally will be, then their driver will win matching against yours, even if yours has a higher probe score.
On macOS 10.15, it should depend on whether or not their kext is in the prelinked kernel/kext cache. Third party kexts can also be included here so it's a little more democratic at least. Dexts can't be in the kextcache though.
I've filed an Apple DTS TSI about this issue and they've acknowledged it as a bug. I strongly recommend you file it as a bug as well to increase chances of it being fixed.
You should be able to work around it in a rather ugly way by explicitly force resetting the device from a user space daemon if your driver didn't manage to grab it. This will cause it to be re-enumerated by the USB subsystem, and for I/O Kit matching to be repeated, at which point your dext hopefully manages to win!
I had developed a kernel extension(kext) by IOKit, but it will be deprecated in the future. So I want develope another driver use dext to replace kext using the DriverKit. But I don't find the executable solutions, like that I cannot find the some class to repalce IOMedia. When I intend to include IOKit in my code,I found the TARGET_OS_DRIVERKIT is 1.
Can someone help me? Thanks a lot!
IOMedia is a subclass of IOStorage and part of the IOStorageFamily. As of the macOS 11.2 SDK (Xcode 12.4) this has not yet been ported to DriverKit.
The SCSIControllerDriverKit API has been in beta since WWDC 2020. It didn't ship with the release versions of macOS 11.0.x-11.2. It's included in the (as of this writing) current betas of 11.3. Perhaps it will see general release with macOS 11.3. This is not a direct port of the storage stack; instead, it's essentially a port of the IOParallelSCSIController KPI. This lets you implement a driver for, well, a SCSI controller. Such a driver can tell the OS about one or more SCSI devices, including block devices, and will start receiving SCSI commands from the system, which it is expected to forward to the underlying controller device. It does not allow you to implement "filter" storage drivers, or to issue SCSI commands to other devices in the system.
Anyone has any experience with application deployment through Mac App Store with 3rd party drivers? I have an application that is used to manage external device through usb port. It requires some drivers to be installed within. Any ideas how to deploy such application with Mac App Store so I don't have to bother user with any confusing messages about drivers? Is there any way to deploy such driver? Is there any way to load drivers only in userspace (sandbox?)
It's a virtual com port driver.
As far as I'm aware, you can use the user space I/O Kit framework from Mac App Store apps. So if your device can be driven entirely via that, go ahead. USB devices are usually good candidates for user space drivers, but it heavily depends on how the device will be used. If only your app is going to be accessing the device, you stand a very good chance. If you're intending to make it available to multiple applications, e.g. by creating a /dev node, you'll need to drop to the kernel.
You can't ship kernel extensions (kexts) with apps via the Mac App Store.
I don't know what the status is regarding MAS apps which require a specific device and kext to work, without shipping the kext together with the app. If the kext is optional, I suspect they'll allow it.
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 created a codeless kext so that one of my USB devices does not get kidnapped by the AppleUSBUHCI driver. When I plug one in, it should be loading a different driver. It happens with both an FTDI and CSR device.
I put together my kext, and the info.plist looks a lot like the example here: http://www.projectosx.com/forum/index.php?showtopic=798 just with different VID/PID.
I ran kextutil with -entZ and the only warning was that I had a different CFBundleId for my personality. I followed the instructions here, Reading and writing to USB (HID) interrupt endpoints on Mac, to get it loaded.
When I loaded the kext, it said it loaded successfully, but I cannot see it with kextstat, and when I plug in my device it still gets hijacked. When I try to do a kextunload, it says the kext was not loaded.
Any help would be appreciated.
From the Apple lists, I learned that codeless kexts will not show up with kextstat unless they link to an existing driver. My personality that linked to the IOKit bundle would only show after load if it had stub code.
For my device, I found an existing driver for similar devices, and first injected a personality into that driver. I was able to verify it loaded when I plugged in my device, and I could open my device. I restored that driver to the original state. Then I created a codeless kext with the personality I had injected in to the existing driver. That driver then got loaded when I plugged in my device and I was then able to communicate with my device.
The solution to my original problem was the CFBundleIdentifier for my original codeless kext and the bcdDevice. From http://lists.apple.com/archives/usb/2009/Aug/msg00050.html, I got hints about different types of codeless kexts and realized I needed to use the CFBundleIdentifier for the existing driver.