[jmux]

The USB-C step is humongous, and hard to implement.

the complexity is high, but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)? users aren’t going to be able to tell the difference (using a cable with no data lines is already a super common issue with people getting into MCUs) so the device needs to be able to tell how much data and power the connected cable can distribute automatically.

this also why usb-c extension cables (M-F) aren’t spec complaint

it’s a real cool port, but the complexity demon is definitely present in the spec :)

[userbinator]

but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)?

By attempting to link up at the highest supported speed and downshifting if there's no valid signal? Ethernet had this figured out decades ago.

[lxgr]

USB-C doesn’t only carry USB data.

I’m not sure if e.g. Displayport even has the capacity for link training (and there are USB-C to Displayport cables that have to support legacy devices that know nothing about USB); HDMI (until 2.2 or so) definitely does not.

It’s ok to not agree with the USB-IF’s tradeoffs in their solutions, but denying the complexity of the problem space can be a hint that you don’t sufficiently understand it to pass that kind of judgement.

[jauntywundrkind]

Intel has a flow for how link training is done on DisplayPort.

Probably shouldn't be surprised but it involves communicating over the AUX channels. Is this something that a sizable % of computers can do? For some reason I thought aux channel was semi free for use, that it could be for Ethernet or USB in a pretty naked form. Didn't realize that needed mode switching?

https://www.intel.com/content/www/us/en/docs/programmable/68...

[lxgr]

Ah, so maybe DisplayPort has mandatory link training then, which would indeed allow unmarked cables.

But to GPs point, there still needs to be a way to tell the source that a given cable is a USB-C-to-DisplayPort one in the first place. So why not include the metadata on what signal grades it’s rated for in that same indicator? That’s exactly what e-markers are.

[userbinator]

It's a protocol they designed, so they could do whatever they wanted between the initial linkup and carrying data, including link training.

but denying the complexity of the problem space can be a hint that you don’t sufficiently understand it

...or that I understand more of it simultaneously to see that it could be made much simpler.

[lxgr]

They did in fact not design all protocols running over USB-C, as I’ve mentioned.

This allows it to work with other ports without putting a complete link speed protocol converter into the cable or adapter.

[theamk]

This means cable might start at speed which is too high and get horrible errors if the cable is bent.

And even with Ethernet, that autorating has plenty of downsides. I've had a cable which I accidentally nailed through, so sometimes it could only connect at 10Mbps. It took me a long time before I realized it needs to be replaced, precisely because it'd just downshift instead of throwing any errors.

[userbinator]

USB has had retries since the beginning, so slowing down the link to adapt to the current conditions isn't anything new.

precisely because it'd just downshift instead of throwing any errors.

That's "a feature, not a bug".