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.
Related
My kext file should be loaded automatically at mac os boot time.
It currently appears in / Library / Extention, but it does not seem to be loaded automatically at boot time.
Is there a way?
For it to load automatically, it must either be an IOKit based kext, or another kext that gets loaded must depend on it.
If it's an IOKit kext, and there is no specific device which should trigger the loading of the kext, you can simply match the IOResources object. The official documentation on device & driver matching talks about how to set up matching in general, and about matching IOResources specifically.
This is new just today. It's been working well for a while now.
When functioning normally, the driver will match on the USB device's
product and vendor IDs, then will load and operate.
It's a USB video adapter so under normal operation, one sees a blurred
image of the desktop until login, then you get a second screen that
works correctly with Display Preferences.
But just today, if the dongle is attached at boot the driver doesn't
load and the USB-attached monitor doesn't show an image.
If I unplug the dongle then plug it back in, it works.
If the dongle is not attached during boot, then plugged in after
reaching the desktop, it works.
If the dongle is attached during boot, and I later use kextutil to
load it, kextutil reports success but it doesn't load.
I speculate it is a problem with matching but don't understand what
could have gone wrong.
It's a signed driver that's now in /Library/Extensions; previously it was unsigned, in /System/Library/Extensions, with System Integrity Protection disabled.
There are two other drivers in the product that are not USB function drivers. They load just fine. All three drivers work together to create a virtual frame buffer then display it.
This could be caused by a bunch of different things. A few suggestions:
Have you verified that ::probe() and ::start() are not being called on your driver class? If they return NULL/false, that will cause behaviour as described.
What's the situation in the IORegistry when your driver has failed to load for a cold-plugged device? Does the nub you match have any client objects?
Have you ruled out a kext cache problem? (E.g. are there any errors when the OS regenerates the kext cache and prelinked kernel?)
Posting your Info.plist might also help - it's possible the problem lies there.
I have a USB device for which I have an API. This API only works if the USB device doesn't use the ftdi_sio/usbserial drivers.
On my laptop, if I plug the USB device in, these drivers get loaded (as modules) and I have to unload them using modprobe -r after which code using the API can see the device.
I have another device which experiences the same issue although no modules are loaded so I'm guessing these drivers are compiled into the kernel. My question is this - is there any way to stop this device from using these drivers or do I have to recompile the kernel, etc?
Thanks for any help!
You are essentially looking for a way to :
unbind the default driver from your USB device
and
bind a driver of your choice to it.
Take a quick look at this to get you started.
A slightly more detailed description of the same is available in this excellent LWN article of (un)binding device drivers.
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.
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.