Closed plinss closed 2 years ago
Thanks for your report. I will change readme to mention that only first port seems to work, and that USB3 works too.
on the Debian host, I have to use the '-r' option with a value >=200 to get it to reliably turn off, otherwise it turns back on after a second or so. The key seems to be repeating long enough to send an 'off' command as it's trying to turn back on. It turns on reliably without the '-r' option, and works fine for both on and off on macOS without the '-r' option.
As described in FAQ, this is Linux USB kernel driver issue. Other operating systems like MacOS or FreeBSD are not affected by this and do not need -r
.
I'm also totally willing to accept that my hub is just broken, since I got it used I have no idea what it's been through, but it does seem to otherwise work normally.
You're right, most USB hubs are broken one way or another :-)
FWIW, doing some research on this I found an article that recommended running:
echo "0" > /sys/bus/usb/devices/usb1/power/autosuspend
echo "auto" > /sys/bus/usb/devices/usb1/power/level
And now I no longer need the -r
option. I'm not sure if both were required or just one as I didn't test them individually. Also not sure if that will survive a reboot, but time will tell. My initial testing was with a SD card adapter (no card present) and a SoloKey V2 (as both have power indicator lights). The actual device I'm using the hub to control is a cheap generic webcam (controlling the power allows me to control the camera's built-in ring light). I found that the -r
option didn't work with the webcam, it would turn off and stay off as long as uhubctl was running, regardless of the value passed, then immediately turn back on when uhubctl exited. The above two commands fixed that and now -r
isn't required at all.
Here's the article that led me to that fix: https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux/12675749#12675749
As stated in FAQ, doing just
echo 0 > sudo tee /sys/bus/usb/devices/${location}.${port}/authorized
before calling uhubctl -a 0 should be enough to not need -r. However, you may need to enable authorization back before turning port back on. Another good way to fix this is to unload camera kernel module so it has no chance to try re-power when device is turned off.
Using very high values for -r (10000+) should work too, as eventually kernel should give up trying to turn on dead device.
I saw the FAQ (but not until I did the above). Just providing the info in case it's useful for anyone.
FWIW, I only ran the commands one time and I can now power the camera on and off with uhubctl and do not need to do anything else, so it may be an easier solution for some devices.
I recently acquired a used j5create JUH470, doing some initial testing with multiple devices plugged in, I'm finding that controlling port 1 controls all the ports, and trying to control other ports has no effect.
The program reports the port condition to be exactly what I specified (e.g. if I turn only port 1 off, it reports all other ports are on).
I'm using the current version 2.4.0 and have tried on both Debian and macOS hosts and get the same result. I'm also using a USB 2.0 extension cable so the host only sees the hub as USB 2.0 capable.
FWIW, on the Debian host, I have to use the '-r' option with a value >=200 to get it to reliably turn off, otherwise it turns back on after a second or so. The key seems to be repeating long enough to send an 'off' command as it's trying to turn back on. It turns on reliably without the '-r' option, and works fine for both on and off on macOS without the '-r' option.
Also, despite #78 stating that the hub only works via USB 2.0, it does work somewhat via USB 3.0 on Debian but only controls Port 1, i.e. none of the other ports turn off at all, but do report being powered off. (Unfortunately my Mac is too old to have USB 3.0 ports).
At the moment I only need to control one device, so this isn't a blocker for me at all. But I'm happy to help debug.
(I'm also totally willing to accept that my hub is just broken, since I got it used I have no idea what it's been through, but it does seem to otherwise work normally.)