Closed michealroberts closed 2 months ago
@krasin Is there a way to call libusb_detach_kernel_driver()
to ensure that we can claim the target interface?
cc @kylelemons Not sure who to ping ...
@krasin Is there a way to call
libusb_detach_kernel_driver()
to ensure that we can claim the target interface?
@michealroberts it's being 11 years since I touched this codebase. Sorry, but my memory returns zero context about it...
@krasin No worries, trying to find the core maintainers for this ... if any are left? :(
Before I review your PR #129, I'd like to see some data to confirm where the issue comes from. Post a result of lsusb -v
for the device in question.
For future reference, the discussion happened mostly in the comment threads of #129 .
The lsusb
output of the problematic device:
002.001 1278:0525 Unknown (Starlight Xpress)
Protocol: (Defined at Interface level)
Configuration 1:
--------------
Interface 1 alternate setting 0 (available endpoints: [0x01(1,OUT) 0x82(2,IN)])
Vendor Specific Class
ep #2 IN (address 0x82) bulk [512 bytes]
ep #1 OUT (address 0x01) bulk [512 bytes]
--------------
and the problem was that the interface number here is not 0 (as expected by the USB for the first interface).
There was an additional problem with the code mentioned in https://github.com/google/gousb/issues/128#issue-2341686861 - that code used intf.Number
as the interface number and alt.Number
as the alternate setting number. This is a mistake, since alt.Number
is always the same as the interface number - the alternate number in the example code should be alt.Alternate
. This is why the code tried to claim Interface(1,1)
rather than Interface(1,0)
and this is why this failed - there was no alternate setting 1. This was as intended. Like reported, calling Interface(1,0)
directly resulted in out of bounds access, as Config.Interfaces
had only a single element (a single interface in the device above), but its Number
was 1, not 0.
I'm perhaps looking more for advice on what is going wrong, but I am seeing this error:
This is my Connect functionality:
But I am somehow not getting the correct interface numbers from the discovery connection to the device, here is the full debug output:
I think the device can be connected to, it's just that the alternative interface numbers are not matching up ...
When I manually change to this:
I get an index out of range panic ...
I am stumped. Is this a firmware issue?
Let me know what other information is needed, if any ...