- Most USB hub chips can be strapped/hard wired configured, or controllable by i2c already directly. Funnily enough this chip isn't, but is extremely cheap (less than 24 cents!).
- The "port enable" feature on this design only controls VBUS (power pin of each connector), not the hub itself, so on a self-powered device it may not actually disconnect the device if it doesn't need VBUS to operate.
Very good points - have you made an Issue on their repo to report these points? As they are currently doing a new revision, it would be good to see these sticking points submitted and get addressed by the devs, if they're not aware of them already.
I do a lot of firmware development and am constantly having to unplug/replug devices during the process .. for this reason I have an I-Tec 16-port Charging Hub, which has individual switches for each port - and this works fine, as long as I get the druthers to launch out of my chair and turn things off and on again... however being able to do all of this remotely, with software, would mean I could a) automate the hell out of a lot of things that requires monkey-tapping, and b) put the whole mess in a closet where it belongs, away from my coffee cup.
So I'm quite eager to see this project proceed - especially if there is a way the port capacities can be expanded (16-port would be ideal) .. so please consider officially reporting any issues in the design that you see!
Don't commercially available software controlled USB hubs exist already? The Yepkit YKUSH 3 came to mind immediately (https://www.yepkit.com/product/300110/YKUSH3) and is the only device I've seen that explicitly says that it disconnects both the data lines and power lines when switching. A casual search also finds https://www.usbgear.com/managed-hubs.html
I don't really see those as issues... The hub chip is cheap and doesn't directly do i2c, but, so ? Controlling VBus seems to be by design, exactly for devices that are separately powered to still work: see author's other project https://github.com/JimHeaney/usb-toggle . There should be a way to block further communication at the software level if that matters to one's use case. You can expand this, just plug a bunch of them into another hub...
I wonder if it supports software control? I haven’t messed with this in a long long time, but here’s a C program for controlling USB port power via software.
It works on a pretty limited set of hubs, because most cheap out on including the switches.
Hub chips often already have pins for per port VBUS control, and you just need to wire P-channel mosfets to them (hub manufacturers often cheap out on this). You can then control port power through sysfs.
In my experience this support was rare. I had an issue a few years ago with multiple USB 3 cameras (Intel Realsense) on a mobile robot that would periodically freeze up and need to be hard-reset, and a power-controllable hub seemed like the least-bad way to hack around it. I found my way to this tool, with its convenient list of compatible hardware:
Of the USB 3 options on the list, several were EOL or impossible to find, and when I ordered one each of the remainder, there was only one I could get working, and it wasn't reliable about being able to reset a device that had frozen to the point where Linux no longer had sysfs entries for it.
We ended up instead using a hub with an internal jumper to disable bus power, and then putting the self power line through a separately-controllable relay.
Last year I bought a second computer for my music studio. I wanted to use the same set of 2 monitors and wired keyboard + trackpad on both machines.
I wrote simple scripts to switch my monitor inputs with keyboard shortcuts (even simpler with Lunar, amazing new Mac app — https://lunar.fyi), which saved me from having to press annoying input-source buttons.
But I couldn't for the life of me find a simple, suitable software controllable KVM switch. That still requires the hardware button to be controlled, so frustrating.
If you or anyone else is still looking for a programmable or controllable USB KVM, though this also comes with a HDMI 2.0 4K 60hz switcher and is accordingly more expensive,
is probably what you need. It has a USB port linked to a USB serial internally that you send strings to switch. It was designed to be used with the Pi KVM/BLIKVM KVM over IP solution but works for other things as well.
For full software no hardware kvm solution, there is Microsoft Garage Mouse Without Borders. Wish it was open source. Mostly useful for multi monitor setup where you don’t need to change sources just change keyboard and mouse. For soft switching source I use a script to send DDC commands to the monitor
Isn't that functionnaly the same as Synergy (which was opensource but isn't anymore), and it's opensource fork Barrier (https://github.com/debauchee/barrier) ?
If you are up for some hardware tinkering, you might be able to modify an existing KVM switch to add remote control.
I had a KVM switch with a wired button (place KVM out of the way, put small button on your desk). The button was connected via a 3.5mm "audio" jack. I never measured the interface, but I bet it just connected two rings of the jack.
Using a switch like that, you can build your own control for it without opening the KVM. Either with an ESP for wifi control (MQTT would be my choice) or a smaller board for USB/serial control (Cortex-M dev board). Short the proper rings via an optocoupler controlled by the MCU and it will behave as if you pressed the button.
I am constantly on the lookout for a monitor that has a USB port/KVM switch built in - it seems like such a no-brainer, but alas there are very few options like this available out there .. I do recall someone making an open-source KVM switcher design some time ago, will have to try and dig it out of the archives ..
Lots of Dell monitors support this - probably every single currently-in-production Ultrasharp supports it, and I think some of the lower tier non-Ultrasharps may support it as well.
Dell monitors all support DDC, I'm not sure if KVM switching can be controlled over DDC but it's likely.
Somewhat unrelated, but some of the Dell monitors also have USB-C support, where a single USB-C cable connects to your laptop and: charges it (Power Delivery from the monitor), hooks up the display (DP alt mode), and connects to the USB hub on the monitor. So if you use a wireless kb/mouse with receivers plugged into the monitor, you'll have literally just 2 cables on your desk - a power cable for your monitor, and a USB-C cable between the monitor and laptop.
- the laptop to the side is awkwardly positioned for zoom chat, so you probably want a webcam as well
- audio is a problem. If you use bluetooth and swap lots of things over then you keep needing to re-pair which is a pain. The model I have (Dell UltraSharp 27 USB-C Hub Monitor - U2722DE) has an audio jack but this is for connecting to soundbars not headphones, and the soundbars Dell offered that are compatible with that monitor don't support headphones. So, I ended up using a USB headset. You can use bluetooth with a usb soundcard dongle to avoid swapping, but bidirectional sound is an issue with that so you'll want to use the mic on the webcam (if you got one like that)
My keyboard/trackball are wired to the monitor, there doesn't seem to be much point to having wireless to attach something that's only a foot away anyway.
Either way, it's one connection to the laptop, but 4-5 other things need to connect to the monitor too. Still pretty good and not too much clutter tho
> I'm not sure if KVM switching can be controlled over DDC but it's likely.
They do. Here's my shell function that helps me switch between DisplayPort-1 + USB uplink cable to the host AND USB-C cable with DisplayPort Alt Mode+Charging+uplink to display's USB hub.
# x0f: DisplayPort-1
# x1b: USB-C
DDC_SOURCES=("x0f" "x1b")
switchkvm() {
local vcp_input_src="x60"
local current next src
current=$(ddcutil -t getvcp ${vcp_input_src} | awk '{ print $4 }')
for src in "${DDC_SOURCES[@]}"; do
if [[ ${src} != "${current}" ]]; then
next=${src}
fi
done
if [[ -z ${next} ]]; then
echo "No eligible alternate input in \$DDC_SOURCES" >&2
echo "\$DDC_SOURCES=(${DDC_SOURCES[*]}); current=${current}"
return 1
fi
ddcutil setvcp "${vcp_input_src}" "${next}"
}
I have a desktop Linux PC but I often need to switch to my MacBook. If I plug the MacBook in, all my peripherals automatically switch to it. If I unplug, everything switch he's back to the Linux PC.
You can definitely use DDC to switch inputs, and the KVM is linked to the selected input. On MacOS I use Better Display which lets me switch inputs from a menu bar app. On linux there is ddcui (which is more like a proof of concept than a polished app, but it works). It's rare that I need to use this though since the auto-switching is usually all I need.
Some exist. I have the Philip 279M1RV, which is 4K 144Hz with a built-in KVM. It's not a perfect monitor, but was the best one I could find for my needs, spec-wise.
What monitor model do you have? I want the same thing, and the Samsung monitor I bought previously doesn't support very much.
Like sibling comment, I have a 4-port USB switch with a remote that connects via micro-usb, it was quite easy to hack a custom remote that I keep next to my keyboard.
I think adding USB to I2C chip and connecting it to USB hub would make device self-contained and great candidate for automated testing of USB hardware - i.e. 3 different hardware revisions which needs to be tested after release of new firmware by test software to verify that all 3 are working the same.
This is very, very handy for development purposes - those of us building firmware and drivers for USB devices are very familiar with the need to reset (unplug/replug) devices during development, and being able to do this with I2C and automatable software procedures is a GODSEND .. I've already started the process of getting a couple PCB's made from this project, and have subscribed for futher updates as the devs get their revision made... this project is very valuable for us in the embedded industry, and I for one would like to see software-controllable USB ports become a very standard thing, personally.
So many issues with USB during development can be resolved if you can just get the device reset during the dev process. Being able to hard-reset a device during compile/debug phases is going to save me huge amounts of time and effort ...
Software controllable USB ports already are a thing, Per-port power switching can be found in the USB 2.0 spec and there's a bunch of hubs out there that implement it, controllable via USB instead of I2C. Since USB 3.2 any device that has downstream type C ports is required to implement PPPS.
Cool, got any suggestions for products that already implement this, particularly those with existing software shims that could be easily integrated into a test suite? I'd be a happy customer if there were such a thing, easily orderable, but I confess I don't quite know what keywords to use to find it ..
"already"? It's something available since USB 1.0 has been created (see section 11.10). For example, it can be automatically used by the Linux kernel (after setting pm_qos_no_power_off to 0), and recently a node to disable a port explicitly has been added as well.
The support for commands themselves (SET/CLEAR_FEATURE) is mandated by the spec, so all hubs support it. However, some hubs don't feature port power control at all (are physically unable to selectively turn off power - you can only turn them all off or not at all), but for those it doesn't matter how you control them ;)
It is extremely rare for USB hubs to support remote power switching of individual USB ports. As someone who develops USB devices, this kind of i2c-controllable hub would save me a lot of cable unplugging.
I've tried a few Amazon Basics ones, and on all of them power switching per-port worked. Uhubctl's compatibility list. seems to confirm my experience. The only problem is that the 7 port ones are in fact two 4-port hubs in a trenchcoat, which makes port numbering a bit weird. Nothing a couple of stickers can't fix, though.
No need to guess. First sentence on the page: "Have you ever wanted to control USB devices using an Arduino, ESP32, or Raspberry Pi? with the i2C USB Hub, you can!"
You can't have a USB hub that can't be controlled over USB, it wouldn't be able to work at all. The spec requires hubs to be active devices that show up on the bus and that can handle requests from the host, such as selective suspend or port power control.
Whether your hub actually offers a physical ability to turn off power of individual ports is another matter. The spec allows port power to be ganged (all ports being disabled at once after all of them have been requested to be disabled) and for all ports to be always powered - you can find out which mode the hub implements by reading wHubCharacteristics field in the hub descriptor.
>You can't have a USB hub that can't be controlled over USB, it wouldn't be able to work at all. The spec requires hubs to be active devices that show up on the bus and that can handle requests from the host, such as selective suspend or port power control.
Irrelevant in this context.
>Whether your hub actually offers a physical ability to turn off power of individual ports is another matter.
And the only matter that counts when it comes to "controllable" USB hubs. If I can't "control" the USB hub with uhubctl (or any other tool) it's not controllable.
You're replying to my comment about an interface used to control such hubs, so it's what you are saying that's irrelevant in this context.
All hubs have means to control them via USB in-band (there are other things to control there than power too), and hubs that do support power switching can be controlled this way, so there's no need to use external interfaces like I2C unless you want to control such hub externally (not from the USB host), which is what this thread was about.
>You're replying to my comment about an interface used to control such hubs, so it's what you are saying that's irrelevant in this context.
Yes. An interface. Because not all hubs can be controlled in-band. Maybe you have a different definition of "control".
>All hubs have means to control them via USB in-band (there are other things to control there than power too), and hubs that do support power switching can be controlled this way, so there's no need to use external interfaces like I2C unless you want to control such hub externally (not from the USB host), which is what this thread was about.
This is wrong though. I can't control my hub. Doesn't matter that there are some other stuff I could theoretically control. (or the OS does without my intervention)
Yes. The Github link is about how to control a USB hub via I2C. From the description:
>Have you ever wanted to control USB devices using an Arduino, ESP32, or Raspberry Pi? with the i2C USB Hub, you can! Turn on or off ports of the USB hub using i2c, as well as control indicator lights and set current limits per-port.
So you saying, that you could do that in-band is wrong, because not all hubs can be controlled in-band.
Or the easy definition: no port control == not controllable.
Nothing's wrong there and you're just playing with semantics to not admit your misunderstanding. All hubs have an in-band control interface available that can be used by them to implement port power control, period.
> The Github link is about how to control a USB hub via I2C.
No, it points to a hardware design for a very specific hub that implemented its port power control via I2C. Usually hubs don't have any I2C interface at all as they don't need one, regardless of whether they do port control or not.
>Nothing's wrong there and you're just playing with semantics to not admit your misunderstanding. All hubs have an in-band control interface available that can be used by them to implement port power control, period.
You want to make it about semantics because you think that "control" means something different then what it means.
There are hubs that can't be controlled that way. Period.
./uhubctl
No compatible devices detected!
Run with -h to get usage info.
Feel free to tell me how I can get those uncontrollable hubs compatible.
This is completely irrelevant to what this subthread is about and you would know that if you had read it again instead of trying to insist that you're right.
What you're writing is still completely irrelevant.
Every USB hub has a control channel over USB and it's true regardless of how you may want to redefine the word "control". My post attempted to answer a question that popped into my mind when looking at this submission: "why would I want a USB hub that implements power control via I2C instead of USB?" (another answer could be "because it's easier to retrofit such functionality on top of a hub chip that doesn't do power control", although that one is only relevant for the designer and not for the user of such device).
Meanwhile, I just sent a command to a USB hub in my mobile phone in order to suspend a modem connected to it - something every USB hub is capable of doing and what can be controlled by the user (yes, it's a function of the hub, not of the device). But you do you, enjoy your world.
The modem (or any other device) has nothing to say when being suspended by the hub - it can't even tell whether it's being suspended selectively or whether it's the whole bus (or any upstream hub) that got suspended. You can suspend every USB device, you have full control over that. With some devices it won't give you any power savings, some won't resume correctly, some will instantly reset and some won't be able to ask the host to be resumed (initiate remote wakeup), but you can send any device to suspend by asking the hub to do so (and telling it to enable or disable remote wakeup capability as desired beforehand) and it will work. You can also ask the hub to disable the port's data connection (PORT_ENABLE) independently of controlling its power (PORT_POWER), and as opposed to power control it's actually mandated by the spec since USB 1.0 and supported universally.
uhubctl doesn't concern itself with all those features, but technically there's nothing preventing it from implementing them alongside power control.
I have spent more time reading USB specs and debugging USB connection troubles than I wish I had to.
I tried to get one (USB3, 4ports, not too pricey) earlier this year, but all the qualifying ones on the list there were either discontinued or had been updated and weren't individually switchable anymore. It's a pity because this would be so handy.
- Most USB hub chips can be strapped/hard wired configured, or controllable by i2c already directly. Funnily enough this chip isn't, but is extremely cheap (less than 24 cents!).
- The "port enable" feature on this design only controls VBUS (power pin of each connector), not the hub itself, so on a self-powered device it may not actually disconnect the device if it doesn't need VBUS to operate.
[1]: https://www.lcsc.com/product-detail/USB-ICs_CoreChips-SL2-1A...