I created a driver using DriverKit on Intel macOS 12.6.1 and Xcode 13.3. I enabled auto-manage signing, and set the signing certificate to 'Sign to Run Locally'. Then, I created a provision profile for the driver and selected my M1 test device. After installing the profile, I ran the app on the M1 device and successfully activated the driver. When I plugin the USB device, I can see the following log: DK: epusbfilter-0x100009dce::start(IOUSBHostInterface-0x10000946d) ok epusbfilter - init com.injection.epusbfilter.dext[57573] Corpse failure, too many 6 I also found a crash log ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: com.injection.epusbfilter.dext [53185] Path: /Library/SystemExtensions/*/com.injection.epusbfilter.dext Identifier: com.injection.epusbfilter.dext Version: 1.0 (1) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 270 Date/Time: 2023-09-19 15:01:01.8502 +0800 OS Version: macOS 13.2 (22D49) Report Version: 12 Anonymous UUID: 5EB7EBD9-A435-FC45-73E6-C2C5844A8082 Time Awake Since Boot: 79000 seconds System Integrity Protection: disabled Crashed Thread: 1 Dispatch queue: Root Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Application Specific Information: abort() called Thread 0: 0 libsystem_kernel.dylib 0x1d5043b78 __semwait_signal_nocancel + 8 1 libsystem_c.dylib 0x1d4fcfec8 nanosleep$NOCANCEL + 212 2 libsystem_c.dylib 0x1d4fee204 sleep$NOCANCEL + 48 3 libdispatch.dylib 0x1d4f807b4 _dispatch_queue_cleanup2 + 200 4 libsystem_pthread.dylib 0x1d50fbc50 _pthread_tsd_cleanup + 132 5 libsystem_pthread.dylib 0x1d50f3220 _pthread_exit + 88 6 libsystem_pthread.dylib 0x1d50f4180 pthread_exit + 88 7 libdispatch.dylib 0x1d4f7bbcc dispatch_main + 128 8 DriverKit 0x1d4d33178 DriverExecutableMain + 84 9 dyld 0x104e95e50 start + 2544 Thread 1 Crashed:: Dispatch queue: Root 0 libsystem_kernel.dylib 0x1d5043720 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1d50f40ec pthread_kill + 268 2 libsystem_c.dylib 0x1d5033cac abort + 180 3 DriverKit 0x1d4d5f890 panic + 256 4 DriverKit 0x1d4d5fa60 __assert_rtn + 88 5 DriverKit 0x1d4d60010 OSMetaClassBase::Invoke(IORPC) (.cold.1) + 44 6 DriverKit 0x1d4d32064 OSMetaClassBase::Invoke(IORPC) + 1396 7 DriverKit 0x1d4d32c5c Server(void*, mach_msg_header_t*, mach_msg_header_t*) + 520 8 DriverKit 0x1d4d3b420 uiomessage(void*) + 180 9 DriverKit 0x1d4d34694 uiomachchannel(void*, dispatch_mach_reason_t, dispatch_mach_msg_s*, int) + 380 10 libdispatch.dylib 0x1d4f8868c _dispatch_mach_msg_invoke + 472 11 libdispatch.dylib 0x1d4f74484 _dispatch_lane_serial_drain + 380 12 libdispatch.dylib 0x1d4f89620 _dispatch_mach_invoke + 852 13 libdispatch.dylib 0x1d4f74484 _dispatch_lane_serial_drain + 380 14 libdispatch.dylib 0x1d4f75130 _dispatch_lane_invoke + 436 15 libdispatch.dylib 0x1d4f7640c _dispatch_workloop_invoke + 1784 16 libdispatch.dylib 0x1d4f7ff5c _dispatch_workloop_worker_thread + 652 17 libsystem_pthread.dylib 0x1d50f5024 _pthread_wqthread + 404 18 libsystem_pthread.dylib 0x1d50fc678 start_wqthread + 8 Thread 2: 0 libsystem_pthread.dylib 0x1d50fc670 start_wqthread + 0 Thread 3: 0 libsystem_kernel.dylib 0x1d504401c __sigsuspend_nocancel + 8 1 libdispatch.dylib 0x1d4f808b4 _dispatch_sigsuspend + 48 2 libdispatch.dylib 0x1d4f80884 _dispatch_sig_thread + 56 Thread 1 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0xffffa0016a011948 x5: 0x0000000000000010 x6: 0x00006000010481b0 x7: 0x0000000000000000 x8: 0x725b4b6e56620c88 x9: 0x725b4b6f3d67bc88 x10: 0x00000000000001b0 x11: 0x0000600001048000 x12: 0x0000000000000090 x13: 0x00000000ffffff92 x14: 0x00000000000007fb x15: 0x0000000080636ffb x16: 0x0000000000000148 x17: 0x00000001d7176c60 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000004003 x21: 0x000000016b05b0e0 x22: 0x0000000000000000 x23: 0x00006000010480e8 x24: 0x0000600001048058 x25: 0xd200fde7d57ecca6 x26: 0x0000000000000085 x27: 0x000060000374c328 x28: 0x0000600001d4c000 fp: 0x000000016b059a90 lr: 0x00000001d50f40ec sp: 0x000000016b059a70 pc: 0x00000001d5043720 cpsr: 0x40001000 far: 0x0000600002c48000 esr: 0x56000080 Address size fault Binary Images: 0x1d503a000 - 0x1d5075fe3 libsystem_kernel.dylib (*) <60df52bd-fc1a-3888-b05b-24b44be3af15> /System/DriverKit/usr/lib/system/libsystem_kernel.dylib 0x1d4fc6000 - 0x1d5039fff libsystem_c.dylib (*) <eee04d9a-7574-3a74-8f4e-cfb05f89f7da> /System/DriverKit/usr/lib/system/libsystem_c.dylib 0x1d4f62000 - 0x1d4fadfff libdispatch.dylib (*) <4e310a5c-9629-305e-a1dd-6632bddd3362> /System/DriverKit/usr/lib/system/libdispatch.dylib 0x1d50ee000 - 0x1d50fdff3 libsystem_pthread.dylib (*) <c1ed564d-b480-3058-937e-b40c3d3df09d> /System/DriverKit/usr/lib/system/libsystem_pthread.dylib 0x1d4d27000 - 0x1d4d6b00d DriverKit (*) <839dc0a2-1e69-38e8-8bf5-ff0ecc531539> /System/DriverKit/System/Library/Frameworks/DriverKit.framework/DriverKit 0x104e90000 - 0x104f1bfff dyld (*) <fe8a9d9e-f65d-34ca-942c-175b99c0601b> /usr/lib/dyld Could anyone please help me with resolving this problem?

After DriverKit being released last year, I wonder if the background mode External accessory communication in Background Modes applies also for drivers made with DriverKit. Is this mode only for products in the MFi group? If so, is there any plans to include DriverKit in this group in order to get data from an external device in the background, which is not in the MFi group?

I'm trying to built a USBDriverKit driver on the Mac. The driver loads properly but when my device is inserted the driver is ignored and instead the com.apple.AppleUserHIDDrivers driver is loaded. I do not understand what is causing this. The device both have USB and HID cababilities but I want it to work with USBDriverKit so that the driver can be used on the Ipad as well. How can I get the driver to match properly? Entitlements: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <integer>1240</integer> </dict> </array> <key>com.apple.developer.driverkit.userclient-access</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> </dict> </plist> Info.plist: ... <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOKitPersonalities</key> <dict> <key>ClickerDriver</key> <dict> <key>IOKitDebug</key> <string>65535</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOClass</key> <string>IOUserService</string> <key>IOProviderClass</key> <string>IOUSBHostInterface</string> <key>IOUserClass</key> <string>ClickerDriver</string> <key>IOUserServerName</key> <string>example.Clicker.driver</string> <key>bInterfaceClass</key> <string>3</string> <key>bInterfaceSubClass</key> <string>0</string> <key>bConfigurationValue</key> <string>1</string> <key>bInterfaceNumber</key> <string>0</string> <key>idProduct</key> <integer>63</integer> <key>idVendor</key> <integer>1240</integer> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>ClickerDriverUserClient</string> </dict> </dict> </dict> <key>OSBundleUsageDescription</key> <string>The app interprets monitors key presses. </string> </dict> </plist> Output of ioreg -b -n "Simple HID Device Demo" -r -l is attacheded. ioreg.log

In Apple Developer Documentation / DriverKit, Notes that "The base DriverKit framework is available ... and iPadOS for devices with an M1 processor.", There is no mention of the M2 and subsequent Apple Silicon chipsets, Does DriverKit work on iPads with M2 and subsequent Apple Silicon chipsets? Apple Developer Documentation / DriverKit : https://developer.apple.com/documentation/driverkit

Why is using control type transfer on the MAC m2 architecture slower than other platforms? The following is my test code, which was tested using the same USB device in Mac m2, Mac x64, and Ubuntu x64 environments. #include <stdio.h> #include <string.h> #include <stdlib.h> #include <libusb.h> #include <sys/time.h> uint64_t get_us() { uint64_t time = 0; struct timeval tv; gettimeofday(&tv, NULL); time = tv.tv_sec * 1000 * 1000 + tv.tv_usec; return time; } int main() { // open usb handle int ret; ret = libusb_init(NULL); libusb_device_handle *usb_handle; usb_handle = libusb_open_device_with_vid_pid(NULL, 0x248a, 0x8266); if (usb_handle == NULL) { exit(1); } ret = libusb_set_auto_detach_kernel_driver(usb_handle, 1); ret = libusb_claim_interface(usb_handle, 0); uint64_t start = get_us(); unsigned char buf[256]; ret = libusb_control_transfer(usb_handle, 0xC1, 0x02, 0x8014, 0, buf, 12, 1000); ret = libusb_control_transfer(usb_handle, 0xC1, 0x02, 0x8014, 0, buf, 12, 1000); ret = libusb_control_transfer(usb_handle, 0xC1, 0x02, 0x8014, 0, buf, 12, 1000); ret = libusb_control_transfer(usb_handle, 0xC1, 0x02, 0x8014, 0, buf, 12, 1000); memset(buf, 0, 256); ret = libusb_control_transfer(usb_handle, 0x41, 0x02, 0x9548, 0, buf, 16, 1000); ret = libusb_control_transfer(usb_handle, 0x41, 0x02, 0x9548, 0, buf, 16, 1000); ret = libusb_control_transfer(usb_handle, 0x41, 0x02, 0x9548, 0, buf, 16, 1000); ret = libusb_control_transfer(usb_handle, 0x41, 0x02, 0x9548, 0, buf, 16, 1000); uint64_t end = get_us(); printf("spent time %ld(us)\n", end - start); libusb_close(usb_handle); libusb_exit(NULL); return 0; } Finally, my conclusion is to call libusb_control_transfer() function on the MAC m2 architecture takes about 10 times slower than the average in x64 architecture. The following are the software running records and wireshark software packet capture records on the MAC m2 architecture. MacBook-Pro % ./libusb_test spent time 22949(us) The following are the running records and wireshark software packet capture records on Ubuntu20 X64. ubuntu20:~$ ./libusb_test spent time 1246(us) From the data captured by Wireshark software, it can be seen that on the MAC m2 architecture, a control transmission takes about 3ms from submission to reply. On the x64 architecture, only around 200us is required. I also tested bulk type transmission, and the performance on the MAC m2 architecture is consistent with that on the x64 architecture. Is this the reason for the MAC m2 architecture USB driver? Is there a solution to this problem?