(PROBLEM): Unable to claim USB device interface

[aloserini]

studio_mac@STUDIOMACsiPro OpenCorsairLink-testing % sudo /usr/local/bin/OpenCorsairLink.elf --debug Checking USB device 0 (1b1c:0c10)... Corsair product detected. Checking if device is Commander PRO... Platform does not support kernel detachment Unable to claim USB device interface DEBUG: scan done, start routines DEBUG: selected device_number = -1

[aloserini]

and Mac shows me the Commander Pro as UPS, any help?

[drasticman]

I'm curious about this as well. Googling around, it seems that a kext called AppleUSBFTDI.kext has been removed in one of the updates to Catalina. I'm too far out of my depth to confirm that myself, though. I'd love to hear if this is the case and if it's fixable going forward -- very curious!

[avhm]

I'm still having this issue too on both master & testing

[jonasmalacofilho]

These days it's apparently very hard to claim HID interfaces on mac OS.

---

@audiohacked, in liquidctl I had to switch to hidapi to work around this.

The good news is that it isn't terribly complicated, and there are some advantages on Linux too (mainly: it doesn't detach the kernel driver, so it's nicer on other programs and the kernel).

The only significant difference is that incoming HID reports are buffered by the kernel, making naive reads yield stale reports.¹

Anyway, I had to do this by manually draining the buffer whenever I need a know fresh read, but there might be a better way if you're directly calling hidapi (liquidctl runs on Pythons, so there's an extra abstraction layer).

¹ With libusb this wasn't an issue on Linux (and probably mac OS) because the kernel driver was detached. But on Windows the problem was always the, as on that platform libusb merely wraps HID APIs.

[wishie]

I was not getting this issue when connecting my H100i Pro directly to the motherboards USB2.0 header... but now that I am using an "NZXT Internal USB Hub" I get the error 'Unable to claim USB device'.

[audiohacked]

Right now OpenCorsairLink doesn't require constant claim to the Corsair devices, but if the software ever gets turned into a daemon, only then the error "Unable to claim USB device" becomes a problem. As it is, you can ignore most any libusb-based errors.

@jonasmalacofilho OpenCorsairLink originally used hidapi, but I felt that it was unnecessary to require two dependencies (libusb and hidapi) when access to Corsair Link compatible hardware required simple commanding as HID protocol isn't used (and the official CorsairLink software wasn't either).

[wishie]

OpenCorsairLink stopped working around the time I got the 'Unable to claim USB device' errors. It was also around the time I connected my H100i Pro and Lighting Node Pro to a USB2.0 hub.

[wishie]

Here you can see, it claims no devices detected.

./OpenCorsairLink.elf --device 0 

Platform does not support kernel detachment
Unable to claim USB device interface
Detected 0 device(s), submitted device 0 is out of range

But lsusb shows otherwise...

2020-06-01 15:26:52.869 system_profiler[4186:42640] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2020-06-01 15:26:52.884 system_profiler[4186:42640] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
Bus 097 Device 001: ID 05e3:0608 Genesys Logic, Inc. USB2.0 Hub 
Bus 097 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB2.0 Hub 
Bus 097 Device 007: ID 1b1c:0c15 CORSAIR MEMORY INC. H100i Platinum  Serial: 7289_2.0
Bus 097 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB2.0 Hub 
Bus 097 Device 008: ID 1b1c:0c0b CORSAIR MEMORY INC. Lighting Node PRO  Serial: 1F200210E00445AF75A6055CC41B00F5
Bus 097 Device 000: ID 0a5c:4500 Broadcom Corp. BRCM20702 Hub 
Bus 097 Device 000: ID 05ac:828d Apple Inc. Bluetooth USB Host Controller 
Bus 000 Device 001: ID 1d6b:IPCI
IPCI
IPCI Linux Foundation USB 3.1 Bus 

[audiohacked]

I see that you are not executing OpenCorsairLink as root/sudo. That is the reason why OCL isn't detecting your devices. (Also, I don't support MacOS since libusb no longer works without hacking the system.)

[wishie]

Are you saying there will be no macOS support going forward?

[jonasmalacofilho]

@audiohacked the use of Hidapi I described was not for compliance with the standards, but for compatibility with macOS.