Mac: hidapi returns empty path for certain USB bus layouts

[todbot]

Over at node-hid/node-hid#169 we've been investigating an issue with hidpai (and thus node-hid) returning empty paths for devices at the end of a multi-USB hub daisy chain.

The issue seems to be that with the change from addressing #266 with commit 59a0767 by @mrpippy, the call to IORegistryEntryGetPath can sometimes fail (see "Discussion" on its man page), because the passed-in path is defined as 512 characters long and some paths are longer than that. (see e.g. below)

Does anyone with more Mac IOKit experience have suggestions on how to solve this? Or is the answer just: don't chain so many USB hubs?

E.g. one path I have with just two physical hubs is 460 characters long: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/USB2.0 Hub @14200000/AppleUSB20Hub@14200000/AppleUSB20HubPort@14210000/USB 2.0 Hub@14210000/AppleUSB20Hub@14210000/AppleUSB20HubPort@14214000/USB 2.0 Hub@14214000/AppleUSB20Hub@14214000/AppleUSB20HubPort@14214300/USB 2.0 Hub@14214300/AppleUSB20Hub@14214300/AppleUSB20HubPort@14214310/blink(1) mk2@14214310/IOUSBHostInterface@0/IOUSBHostHIDDevice@14214310,0
if I add another hub, I can still access the device via libusb but not via hidapi.

[mrpippy]

Ah very interesting, I guess the IOKit designers never anticipated a path this long!

One of the other suggestions from #266 was to use IORegistryEntryGetRegistryEntryID() to get the unique 64-bit registry entry ID, rather than the path. I think that's the right thing to do: avoids this problem, and apparently works correctly for Bluetooth devices (a problem that Chromium was having). Downside is that the path isn't human-readable at all, but I think that's outweighed.

[gzphreak]

Perhaps but the path, and I could be totally off base here, is not very readable once you have more than a few hubs or devices.

[mrpippy]

True, out of that 460 character path, only a few chars (blink(1)) are really useful. I think it's still better than a random 64-bit number, but human-usefulness-of-path is way lower on the priority list than having the library work right with any USB topology.

[zakalawe]

Just got bitten by this, with the USB hub in my monitor, which is attached over Display Port, to a USB-C hub - so the path ends up being enormous. Frustratingly, the C++ API to IORegistryEntry supports passing larger buffers than an io_string_t - but calling the C++ API from hidapi.c will be slightly tricky.

https://github.com/apple/darwin-xnu/blob/master/iokit/Kernel/IOUserClient.cpp#L2794 is the C wrapper around the C++ API we'd ideally use here.