search

libusb / libusb

A cross-platform library to access USB devices
https://libusb.info
GNU Lesser General Public License v2.1
5.26k stars 1.91k forks source link

Last version (1.0.21/1.022) does not list all connected devices on macOS Sierra #290

Closed amok closed 4 years ago

amok commented 7 years ago

On master branch (seems version 1.0.21) device (STM32VLDiscovery board in my case) doesn't show up in list of connected devices, but on tag v1.0.9 it does.

Related to texane/stlink/issues/574 (and comment)

➜  ~ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.12.3

libusb@master devices list

➜  libusb git:(master) ./examples/testlibusb
Dev (bus 20, device 5): Broadcom Corp. - Bluetooth USB Host Controller

libusb@v1.0.9 devices list

➜  libusb git:(f98eaca) ✗ ./examples/testlibusb
Dev (bus 20, device 0): 05AC - 8007
Dev (bus 20, device 5): Broadcom Corp. - Bluetooth USB Host Controller
Dev (bus 20, device 10): STMicroelectronics - STM32 STLink

➜  libusb git:(f98eaca) ✗ ./examples/listdevs
05ac:8007 (bus 20, device 0)
05ac:8290 (bus 20, device 5)
0483:3744 (bus 20, device 10)

Please let me know if you need some more debugging info.

xor-gate commented 7 years ago

I think the device is bound to a kernel driver as mentioned here:

https://github.com/libusb/libusb/wiki#supported-environments

Note: the device should not be bound to a kernel driver. You can use a codeless kext to achieve that if there is a kernel driver (eg: HID or USB Mass Storage) which already binds to the device.

As the Stlink v1 programmer uses the SCSI transport (compared to Stlink v2 which uses RAW transport).

Marc-Aldorasi-Imprivata commented 7 years ago

This also worked in 1.0.20. It appears to be caused by 871eb29 and b7526c1, and can be worked around by applying the following patch:

diff --git a/libusb/os/darwin_usb.c b/libusb/os/darwin_usb.c
index 9946222..42fcc6e 100644
--- a/libusb/os/darwin_usb.c
+++ b/libusb/os/darwin_usb.c
@@ -516,7 +516,7 @@ static void darwin_check_version (void) {
   errno = 0;
   version = strtol (version_string, NULL, 10);
   if (0 == errno && version >= 15) {
-    darwin_device_class = "IOUSBHostDevice";
   }
 }

@@ -882,7 +882,7 @@ static int get_device_parent_sessionID(io_service_t service, UInt64 *parent_sess

   /* Walk up the tree in the IOService plane until we find a parent that has a sessionID */
   parent = service;
-  while((result = IORegistryEntryGetParentEntry (parent, kIOServicePlane, &parent)) == kIOReturnSuccess) {
+  while((result = IORegistryEntryGetParentEntry (parent, kIOUSBPlane, &parent)) == kIOReturnSuccess) {
     if (get_ioregistry_value_number (parent, CFSTR("sessionID"), kCFNumberSInt64Type, parent_sessionID)) {
         /* Success */
         return 1;
hjelmn commented 7 years ago

This is an odd issue. For some reason on Sierra and High Sierra the matching dictionary is not matching all devices of class IOUSBHostDevice. I can confirm it does work when matching IOUSBDevice. Not sure this is the correct fix. Digging into it now.

Looks like AppleUSBDevice as the matching class also works.

JeremyAgost commented 7 years ago

Is there a reason you think it's "better" to use the IOServicePlane rather than the IOUSBPlane? Presumably we only care about parent relationships for devices that are visible in the IOUSBPlane. I'm also not sure that AppleUSBDevice is the right matching class because I believe that will only match a subset of USB device classes. Not every USB device is matched by the AppleUSBDevice class, since they can be claimed by non-Apple drivers.

EricG-Personal commented 6 years ago

Is there any progress on this issue? I am experiencing the same problem.

If it helps, there are two terminal commands I can issue to show all of the devices or at least the devices I care about:

  1. ioreg -p IOUSB -w0 -l

  2. system_profiler SPUSBDataType

I am using macOS 10.13.3

EricG-Personal commented 6 years ago

I did build and try the latest 1.0.22-rc3 release which mentioned improved support for Sierra and High Sierra in the release notes, but it exhibits the same problem.

JeremyAgost commented 6 years ago

You should try my company's fork, https://github.com/GroundControl-Solutions/libusb. We had to fix some hotplug detection issues as I recall to ensure all devices are found on Sierra and High Sierra.

mcuee commented 6 years ago

In my case, I only see the Apple root hub (05ac:8086) is not listed in the latest version compared to libusb-1.0.20.

MyMacMini:libusb-1.0.20 xiaofanc$ ./examples/listdevs 
05ac:8281 (bus 250, device 7) path: 1.1.3
046d:c52b (bus 253, device 4) path: 1.2
1a40:0101 (bus 250, device 4) path: 1.3
0403:6001 (bus 250, device 3) path: 1.2
0fcf:1009 (bus 253, device 3) path: 1.3
05ac:8242 (bus 253, device 2) path: 1.1
0a5c:4500 (bus 250, device 2) path: 1.1
0424:2513 (bus 253, device 1) path: 1
0424:2513 (bus 250, device 1) path: 1
05ac:8006 (bus 250, device 0)
05ac:8006 (bus 250, device 0)

MyMacMini:libusb xiaofanc$ ./examples/testlibusb
Dev (bus 250, device 7): Apple Inc. - Bluetooth USB Host Controller
Dev (bus 253, device 4): Logitech - USB Receiver
Dev (bus 250, device 4): 1A40 - USB 2.0 Hub
Dev (bus 250, device 3): FTDI - FT232R USB UART
Dev (bus 253, device 3): Dynastream Innovations - ANT USB-m Stick
Dev (bus 253, device 2): Apple Computer, Inc. - IR Receiver
Dev (bus 250, device 2): Apple Inc. - BRCM20702 Hub
Dev (bus 253, device 1): 0424 - 2513
Dev (bus 250, device 1): 0424 - 2513

MyMacMini:libusb xiaofanc$ pwd
/Users/xiaofanc/work/libusb/libusb
MyMacMini:libusb xiaofanc$ ./examples/listdevs 
05ac:8281 (bus 250, device 7) path: 1.1.3
046d:c52b (bus 253, device 4) path: 1.2
1a40:0101 (bus 250, device 4) path: 1.3
0403:6001 (bus 250, device 3) path: 1.2
0fcf:1009 (bus 253, device 3) path: 1.3
05ac:8242 (bus 253, device 2) path: 1.1
0a5c:4500 (bus 250, device 2) path: 1.1
0424:2513 (bus 253, device 1) path: 1
0424:2513 (bus 250, device 1) path: 1
mcuee commented 6 years ago

Okay, I inserted an iPhone (05ac:12a8) and I can reproduce this issue. 1.020 can see the device. Latest git can not.

MyMacMini:libusb-1.0.20 xiaofanc$ ./examples/listdevs 
05ac:12a8 (bus 250, device 6) path: 1.3.2
0bda:0109 (bus 250, device 5) path: 1.3.4
05ac:8281 (bus 250, device 7) path: 1.1.3
046d:c52b (bus 253, device 4) path: 1.2
1a40:0101 (bus 250, device 4) path: 1.3
0403:6001 (bus 250, device 3) path: 1.2
0fcf:1009 (bus 253, device 3) path: 1.3
05ac:8242 (bus 253, device 2) path: 1.1
0a5c:4500 (bus 250, device 2) path: 1.1
0424:2513 (bus 253, device 1) path: 1
0424:2513 (bus 250, device 1) path: 1
05ac:8006 (bus 250, device 0)
05ac:8006 (bus 250, device 0)

MyMacMini:libusb xiaofanc$ ./examples/listdevs 
0bda:0109 (bus 250, device 5) path: 1.3.4
05ac:8281 (bus 250, device 7) path: 1.1.3
046d:c52b (bus 253, device 4) path: 1.2
1a40:0101 (bus 250, device 4) path: 1.3
0403:6001 (bus 250, device 3) path: 1.2
0fcf:1009 (bus 253, device 3) path: 1.3
05ac:8242 (bus 253, device 2) path: 1.1
0a5c:4500 (bus 250, device 2) path: 1.1
0424:2513 (bus 253, device 1) path: 1
0424:2513 (bus 250, device 1) path: 1
JeremyAgost commented 6 years ago

Later today I should have time to pull-request from our branch to resolve that issue.

mcuee commented 6 years ago

@JeremyAgost Now 1.022 has been released, can you get the pull-request against latest git? Thanks.

mcuee commented 4 years ago

My Mac Mini died. Is this issue still there in the master git?

JeremyAgost commented 4 years ago

In the product that we integrate libusb, we've simply dropped support for macOS Sierra partly because of this issue. We're not set up to test with those earlier OS versions anymore. Sorry I can't help more.

mcuee commented 4 years ago

@JeremyAgost Thanks for the update. Can you confirm that High Seirra macOS 10.13 (successor to Sierra macOS 10.12) has no issue? Thanks. And hopefully 10.14 Mojave and 10.15 Catalina are okay as well.

mcuee commented 4 years ago

https://github.com/stlink-org/stlink/issues/574

The above stlink issue says that 1.0.23 sorted out the issue.

Here we actually had two separate problems in one issue:

libusb problems with device detection in macOS: Bug in external libusb library, solved in v1.0.23, which is also distributed via the package repositories homebrew and MacPorts per default. Thus this is no longer an issue.

ST-Link-v1 driver issue relates to Kernel Extensions (kext): Closed by commit 59c5cfd.

mcuee commented 4 years ago

https://github.com/libusb/libusb/pull/428

It seems this has been fixed in Pull Request 428 and release 1.0.23.

amok commented 4 years ago

Then I'm closing this. Ping me here to reopen in case the issue persists

hjelmn commented 3 years ago

Coming back around to this. From what I can tell this is a bug in 11.12.x and other macOS releases. Even though the iPhone shows up as class IOUSBHostDevice it doesn't show up in the device iterator for that class. Apple fixed this by macOS 11.

There are benefits to going back to using IOUSBHostDevice so I will look for a workaround that works with all versions until we no longer support the last broken version (I will check 10.13 and 10.14).