I'm developing a DriverKit USB driver for iPadOS that needs to communicate with a vendor-class USB device (bInterfaceClass = 0xFF) as I need to communicate with a USB device using a custom protocol over IOUSBHostPipe for bulk transfers.
Current Configuration:
- Info.plist: IOProviderClass = IOUSBHostDevice
- Device: bDeviceClass = 0, bInterfaceClass = 0xFF (vendor-specific)
What Works:
- Driver matches and loads successfully
- Start_Impl() executes
- device->Open() succeeds
- device->SetConfiguration() succeeds
The Problem:
-
uintptr_t iterRef = 0;
-
kern_return_t ret = device->CreateInterfaceIterator(&iterRef);
-
Result: ret = kIOReturnSuccess (0x0), but iterRef = 0 (empty iterator)
What I've Tried:
- Matching IOUSBHostInterface directly - Driver is loaded, but extension never executed
- Current approach (IOUSBHostDevice) - Driver extension loads and starts, but CreateInterfaceIterator returns empty
Question:
Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for vendor-class (0xFF) USB devices?
I'm developing a DriverKit USB driver for iPadOS.
So, my first and strongest recommendation is that you shift your development environment from iPadOS to macOS, even if you never intend to ship on macOS. I have a more extended post on this here, but the basic summary is that, in my experience, the higher friction, lower visibility, and lack of critical investigator tools [1] on iPadOS mean that you'll end up wasting far more time trying to figure out “what’s happening on iPadOS" than you saved by not getting a minimal macOS implementation working.
[1] In particular, I consider IORegistryExplorer to be an absolutely critical tool for driver developers. See this forum post for download instructions and general guidance on using it.
That leads to here:
Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, in iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for vendor-class (0xFF) USB devices?
Yes, that should also work. I'm not sure of the exact issue (see below for my best guess), but if we weren't willing to let you control that device, we wouldn't have allowed your DEXT to match against it at all. Whatever is happening is an issue with your driver, not the system.
NOW, putting on my psychic debugging hat, I'm going to guess that the problem is that your "IOKitPersonalities" dictionary includes "IOMatchCategory". As described in this post I put up yesterday, including that key in a DEXT will enable non-exclusive matching. In the case of a USB driver, that means the system driver will load "beside" your driver and then open the provider nub, blocking your access to the same nub.
That situation is clearly visible in IORegistryExplorer, where you'll see two drivers loaded above the device instead of just one. More to the point, if that’s not what’s going on then my standard next step is to ask you to file a bug and then upload an IORegistryExplorer snapshot, so I can see what’s going on.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
