> For a while, I do not believe the USB transaction translator[1] was not totally commonplace: I remember articles specifically highlighting which usb2 hubs had

> For a while, I do not believe the USB transaction translator[1] was not totally commonplace: I remember articles specifically highlighting which usb2 hubs had this feature. You are misremembering. All 2.0 hubs have TTs. The question is whether they have one (same problem as USB3, all ports share a single 12Mbps pipe in 1.0 mode) or multiple (can aggregate multiple 12Mbps devices without bottlenecks). What USB3/4 have done is doom us to a world equivalent to multi-TT hubs not existing. Except it's worse because with single TT hubs, at least you can still chain multiple to a parent hub and aggregate without bottlenecks at that level. > Once we start adding isosynchronous profiles & perhaps various other usb2 gimmicks, I imagine the transaction translation problem becoming much more thorny Thorny, perhaps. Impossible, no. This is trivial to prove: sticking a PCI USB2 host controller behind a Thunderbolt/USB4 bridge works fine, and that is for all intents and purposes a USB2 to TB/PCIe "transaction translator", and PCIe itself is more like Ethernet and can be tunnelled over almost anything. The USB host transaction layer (which is a pretty 1:1 map to xHCI) is tunnelable just fine (this is how USB over the network protocols work too, with host support). It's the wire layer that isn't, because once you drop to that layer you can't reconstruct or control the original transaction states properly. What USB2 did for TTs is extend the protocol in such away that the missing information/cases could be handled properly, with cooperation from the host. There's no reason why they couldn't have done this for USB2 to 3 too. > Making a hub that passes through usb4, but which also exposes a variety of simple peripherals is much easier without mandating the transaction translator. As I said, they could still keep the USB 2 lines. Having TT support in the standard doesn't mean hubs have to implement it. We'd still have the differentiation between TT-ful and TT-less hubs if you want. The problem is, right now, TT-ful USB3 hubs aren't possible. I agree that having the 2.0 lane in Type C makes a ton of sense. Just let me tunnel it over the SS lanes too! Source: I've written USB support for projects way too often, including a bare-bones OHCI driver once. I also authored the virtual xHCI implementation in qemu.