Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve USB2/3 duality matching #288

Merged
merged 1 commit into from Dec 7, 2020
Merged

Improve USB2/3 duality matching #288

merged 1 commit into from Dec 7, 2020

Conversation

mvp
Copy link
Owner

@mvp mvp commented Nov 26, 2020

@sre, @jfberry: this PR should fix (or at least considerably improve) device correlation problem #248.
Can you please try it?

git clone https://github.com/mvp/uhubctl -b usb3-duality
make
./uhubctl -l {path}

It should do matching almost always correctly.
However, it may still fail if you connect 2+ completely identical hubs (with the same container IDs), but even this should work correctly if you daisy-chain them.

If you confirm that it works for you, I will merge it to master branch.

@jfberry
Copy link

jfberry commented Nov 26, 2020

I don't have the hub in easy access right now, hoping @sre does (and in some ways, since you now have the same hub, that test will be more interesting)

@mvp
Copy link
Owner Author

mvp commented Nov 26, 2020

@jfberry, this works for me on MacOS with Rosonway 16 port hub.
But, I wanted to get more confirmations from other people affected, like you :-)

@mvp
Copy link
Owner Author

mvp commented Nov 26, 2020

@Roeeklinger60, can you try this too?

@thesocialproxy
Copy link

Hey,

@mvp I have about 40 of these hubs connected to a few servers in the office, I tested this but as you predicted it is not working correctly if you have 2 of the same exact hubs connected at the same time (Linux).

I have been using a wrapper script that takes the USB2 hub number + 1 and it is working just fine for a few months now, however, if you find a way to do it properly this would be super helpful to me.

Let me know if you need me to do any more tests, I have a lot of these here, I can even give you remote access if you like,
Thanks!

@mvp
Copy link
Owner Author

mvp commented Nov 27, 2020

Approach taken in this PR can be extended to give even higher matching priority when USB2 bus + 1 == USB3 bus. This should solve your issue. I will try to code it in...

@mvp
Copy link
Owner Author

mvp commented Nov 27, 2020

@Roeeklinger60, I have added bumping matching priority when usb2bus+1==usb3bus.
Please give it a try and see if it is working now. Thanks!

@mvp
Copy link
Owner Author

mvp commented Dec 1, 2020

@Roeeklinger60, can you please try this on your setup? It works for me, but I wanted to make sure we have broader testing done. Thanks!

@thesocialproxy
Copy link

thesocialproxy commented Dec 3, 2020

Hey, sorry for the late reply, this is still not working right for me, it seems to be selecting the wrong hubs (last ones?)

root@raspberry:~/uhubctl# uhubctl -l 3-1 -p 2 -a 0
Current status for hub 14-1.4.4 [2109:0817 VIA Labs, Inc. USB3.0 Hub, USB 3.10, 4 ports]
  Port 2: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 14-1.4.4 [2109:0817 VIA Labs, Inc. USB3.0 Hub, USB 3.10, 4 ports]
  Port 2: 00a0 off
Current status for hub 3-1 [2109:2817 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0000 off
Sent power off request
New status for hub 3-1 [2109:2817 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0000 off
root@raspberry:~/uhubctl# uhubctl -l 4-1 -p 2 -a 0
Current status for hub 13-1.4.4 [2109:2817 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0503 power highspeed enable connect [12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE]
Sent power off request
New status for hub 13-1.4.4 [2109:2817 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0000 off
Current status for hub 4-1 [2109:0817 VIA Labs, Inc. USB3.0 Hub, USB 3.10, 4 ports]
  Port 2: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 4-1 [2109:0817 VIA Labs, Inc. USB3.0 Hub, USB 3.10, 4 ports]
  Port 2: 00a0 off

@mvp
Copy link
Owner Author

mvp commented Dec 4, 2020

This is really weird, it should work @Roeeklinger60.

Can you please paste output for running this:

git clone https://github.com/mvp/uhubctl -b usb3-duality
make
sudo ./uhubctl

(you probably want to use https://gist.github.com if your output is too long).
Thank you!

@mcuee
Copy link

mcuee commented Dec 6, 2020

Some test results in #282 on my Mac Mini M1 posted.

@mvp
Copy link
Owner Author

mvp commented Dec 6, 2020

@Roeeklinger60, @mcuee, @jfberry: I have just pushed better handling for USB3 duality.
It should work on Linux for multiple identical USB3 hubs.

It works for me on Mac with Rosonway 16 port hub.

Also, I expect that it will work properly on M1 Mac.

git clone https://github.com/mvp/uhubctl -b usb3-duality
make
./uhubctl -l {path}

Please test and report if this works better. Thank you!

@mcuee
Copy link

mcuee commented Dec 7, 2020

Here are the test result under my Mac Mini M1, native M1 ARM64 build, with a TP-Link UH700 USB 3.0 hub.

mcuee@mcuees-Mac-mini test % git clone https://github.com/mvp/uhubctl -b usb3-duality
Cloning into 'uhubctl'...
remote: Enumerating objects: 633, done.
remote: Total 633 (delta 0), reused 0 (delta 0), pack-reused 633
Receiving objects: 100% (633/633), 185.80 KiB | 332.00 KiB/s, done.
Resolving deltas: 100% (391/391), done.

mcuee@mcuees-Mac-mini test % cd uhubctl

mcuee@mcuees-Mac-mini uhubctl % git branch
* usb3-duality

mcuee@mcuees-Mac-mini uhubctl % make
cc  -g -O0 -Wall -Wextra -std=c99 -pedantic -DPROGRAM_VERSION=\"2.2.0-24-g074d0322\" -I/opt/homebrew/Cellar/libusb/HEAD-442305e/include/libusb-1.0 uhubctl.c -o uhubctl -L/opt/homebrew/Cellar/libusb/HEAD-442305e/lib -lusb-1.0

mcuee@mcuees-Mac-mini uhubctl % ./uhubctl 
Current status for hub 2-1.1 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0100 power
  Port 4: 0100 power
Current status for hub 2-1 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 1: 0503 power highspeed enable connect [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0100 power
  Port 3: 0100 power
  Port 4: 0503 power highspeed enable connect [0ac8:3420 Vimicro Corp. PROLiNK PCC3220]
Current status for hub 2-5.1 [0bda:0411 Generic 4-Port USB 3.0 Hub, USB 3.00, 4 ports]
  Port 1: 0203 power 5gbps U0 enable connect [05e3:0749 Generic USB3.0 Card Reader 000000001536]
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 2-5 [0bda:0411 Generic 4-Port USB 3.0 Hub, USB 3.00, 4 ports]
  Port 1: 0203 power 5gbps U0 enable connect [0bda:0411 Generic 4-Port USB 3.0 Hub, USB 3.00, 4 ports]
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect

mcuee@mcuees-Mac-mini uhubctl % ./uhubctl -a off -p 4 -l 2-1
Current status for hub 2-1 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 4: 0503 power highspeed enable connect [0ac8:3420 Vimicro Corp. PROLiNK PCC3220]
Sent power off request
New status for hub 2-1 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 4: 0000 off
Current status for hub 2-5 [0bda:0411 Generic 4-Port USB 3.0 Hub, USB 3.00, 4 ports]
  Port 4: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 2-5 [0bda:0411 Generic 4-Port USB 3.0 Hub, USB 3.00, 4 ports]
  Port 4: 00a0 off

@mvp
Copy link
Owner Author

mvp commented Dec 7, 2020

Thank you @mcuee , that looks perfect. I will commit this change to master branch :-)

Use priority based duality matching.

* Support Raspberry Pi 4B better (as it has USB2 hub one level deeper than its USB3 counterpart).
* Support M1 Macs (as they seem to place all USB devices to bus 2).
* Support Apple mini-dock (it advertises 2 USB2 ports but only 1 USB3 port).
* Should support multiple identical hubs (with the same container id) on Linux.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants