diablodale
commented
1 year ago My guess, the function path code doesn't handle a computer with multiple USBROOT aka USB controllers. This is my laptop. It has three USB-3 type-A ports. And it has one USB-3 type-C port. I have two OAKs on the type-As. And one OAK on the type-C.
Notice above there are three USB controllers. That aligns with the the 3.1 native libusb port path. libusb saw the three controllers.
If I have only one OAK 14442C10C1A1C6D200 plugged into the type-C it has the long path
PCIROOT(0)#PCI(1B00)#PCI(0000)#PCI(0200)#PCI(0000)#USBROOT(0)#USB(3)
ACPI(_SB_)#ACPI(PCI0)#ACPI(RP17)#ACPI(PXSX)#ACPI(TBDU)#ACPI(XHC_)#ACPI(RHUB)#ACPI(SS01)and looks like this
themarpe
getWinUsbMxId()does not correctly transform Win32 location paths into libusb port paths. This causes failure(s) to find USB devices.getWinUsbMxId()is a fallback function that is used only on Windows when libusb finds aX_LINK_BOOTEDdevice that it can't access due to other app/code having that device already open via libusb; there is no shared access.getWinUsbMxId()uses the Win32 nativeSetupDiapi to query for usb devices. Then the function attempts to map the Win32 "Location path" into a libusb path of ports. Unfortunately, this mapping is errant and therefore devices are often not found since the path's will not match.Setup
develop88d81da8f0f5c1c6e79b9ff7d94f335ce16e036a with a LOT of debug outputRepro
while(true)loopcolor_camera_node_testin first terminal and wait until it is in the loop. Observe the debug output. LEAVE IT RUNNING!color_camera_node_testin second terminal and wait until it is in the loop. Observe the debug outputResult
First terminal
Notice the probe of the 3 devices by running the small program on each. Then the chosen device is connected+started.
Second terminal
Here the bug is exposed. It again probes all three devices. The 1st and 2nd can run the small program to probe them. However, the 3rd device is running in the other terminal and therefore can not be opened. It is "libusb device is BOOTED and LIBUSB_ERROR_ACCESS" which leads to the windows-only fallback function
getWinUsbMxId().getWinUsbMxId()calls Win32SetupDiapis, parses for serial numbers in the DeviceInstanceId, and attempts to transfor the Windows path into a libusb port path. In the logs below "seeking..." is the params passed togetWinUsbMxId(). It is seeking vid=03e7 pid=f63b at libusb_path="3.20".Remember that terminal 1 has one device open. Look below in the "candidate" entries. Each candidate is the vid, pid, and custom mapping path contructed; just before the if() test. Easy to see in the devbug all three OAK devices since they all have the same vid=03e7.
UNBOOTED are... pid=2485 simulatedpath=1.9 pid=2485 simulatedpath=1.1
BOOTED is... pid=f63b simulatedpath=1.20 👎😢
The function was given libusb port path "3.20" yet the simulated mapping generated "1.20". This is errant.
These are the Windows Device Manager location paths for the two running Luxonis Devices during the above logs.
Expected
device on libusb path "3.20" is found using the Win32 apis and its MXID returned