macOS: Fix set_configuration and reset by using USBDeviceOpen

[kevinmehall]

Fixes #87

USBDeviceOpen is not required for claiming interfaces. The documentation says it's required for control transfers, but it works without. It is, however, required for set_configuration and reset.

Having an interface claimed does not cause set_configuration and reset to fail on macOS like it does on Linux. After doing some testing, I ended up doing what libusb does and attempting to USBDeviceOpen when opening a device to try to get exclusive access, but ignoring failures, and trying again and requiring success only before set_configuration and reset. That's not perfect -- you can be the second process to open a device and fail USBDeviceOpen, then the first process closes it, and a third process is then able to call these methods, but I can't find a better way.

[carlossless]

I have tested this against my project and it does seem to work. Though, I'm curious why not use USBDeviceOpenSeize() instead of USBDeviceOpen() same as libusb does.

Only USBDeviceOpenSeize is documented, but given that the docs state that it opens the device for exclusive access I assume USBDeviceOpen is the non-exclusive variant.

Having this in mind, shouldn't USBDeviceOpenSeize be used here?

[kevinmehall]

Though, I'm curious why not use USBDeviceOpenSeize() instead of USBDeviceOpen() same as libusb does.

The old documentation describes both:

• USBDeviceOpen: Open up the IOUSBDevice for exclusive access.
• USBDeviceOpenSeize: Open up the IOUSBDevice for exclusive access. If another client has the device opened, an attempt is made to get that client to close it before returning.

I don't know what it does to the other app, but that doesn't seem like the desired behavior. I guess that means I should test what happens when libusb opens a device that nusb has already opened.

[carlossless]

that doesn't seem like the desired behavior

Yep, I agree.

I guess that means I should test what happens when libusb opens a device that nusb has already opened.

I dug a bit more and found this description. Assuming everything behaves the same way since that was published, I would expect that: if the app that's holding exclusive access to a device doesn't register to receive those IOServiceInterestNotifications and act on them, both USBDeviceOpen and USBDeviceOpenSeize will fail in the same way.