Comment by bitwize | Hacker News Reader

Comment by bitwize | Hacker News Reader

OK, remember when modems were like EEEEEEEkRrRrRrRrRrRrRbaBONGbaBONG....

That was handshaking, and it was how modems figured out which speeds and protocols each other supported so they could figure out how fast to transfer data and how to encode it.

Monitors are kind of the same. There's handshaking that goes on each time you connect a monitor to a video source.

Like (and I'm totally making this up):

- Hi, I'm an AMD video card.

- Hi, I'm an LG monitor.

- You're a monitor? Great! I have some data I'd like to display. What resolutions, refresh rates, and color depths do you support?

- Well, I support 1920x1080x24bpp@60Hz, and 1600x900x24bpp@70Hz, and...

- Cool! I'd like to display at 1920x1200x24bpp@60Hz, please.

- Sure thing, hang about while I get that set up.

[Monitor CPU sets up whatever framebuffers, scalers, etc. are necessary to display at 1920x1200x24bpp@60Hz]

- Right then. Ready for your first frame.

- All right, first frame incoming...

Only then will you get your display. This can take a couple seconds.

> Monitors are kind of the same. There's handshaking that goes on each time you connect a monitor to a video source.

If the connector is high bandwidth enough to send hundreds of thousands of pixels 60 times a second, how can it possibly be so slow to send a few bytes of handshake or EDID data?

Handshakes should be happening nearly instantly. You can complete opening a TCP connection to the other side of the world in a fraction of the time it takes to switch input on the average monitor.

There's a major difference between the data-plane (the lanes where frames go from the signal source to the display) and the control-plane (the command and control channel that is bidirectional and used to discover a peer and negotiate settings).

The former is indeed very high speed, in the order of gigabits per second (up to 48gbps in later iterations), whereas the latter can seem ancient in comparison - 500bps to 115.2kbps - several orders of magnitude slower. The reason is that while the high data rate bus is handled by powerful, dedicated hardware (GPUs and ASICs/FPGAs), the control plane is usually done by micro-controllers (or otherwise lower-power devices) that are responsible for general management of the display. Sure, it would be nice if they had more powerful hardware and a faster bus, but those changes usually aren't what people are shopping for and so the standards committees aren't pushing makers to make these changes...

Example EDID: https://edid.tv/edid/752/ (one can also go through a github link at the bottom)

Most EDIDs are 256 bytes in that repo. At 500bps it may take seconds to transmit, but 115.2kbps (14kbytes/s) is enough to do it in an instant.

As usual, the issue is probably not a bus speed or a chip cost itself, but a crappy legacy timeout-based negotiation process which nobody touched or restandardized since it was slapped together. You can’t just autoupdate all compatible hardware in the world and move on.

My blind economical guess is that one couldn’t even find controllers today which are slow enough to DDC back and forth in seconds, because the package/assembly probably takes 95% of the cost anyway. Please correct me on that, I’m curious.

But why does it take a couple of seconds? I can send a ping thousands of kilometers away and get the ICMP reply in 100 ms or something. I can ping my router in less than a millisecond and my router is further away than my computer.

Why does this whole negociation take seconds and not milliseconds?

Or my car: it's full of electronics. Chips and code everywhere. Even my pedals, which used to be cables decades ago, are now fly-by-wire. It's chips and code everywhere.

Yet feedback is instant.

Now I understand a monitor is not the same as ethernet and is not the same as a car but... Seconds?

Ping: your device, your router, your ISP's router, etc are already up and running and ready to participate in protocol interactions. Having done a bit of networking in the days where it was still reasonable to use analog modems as backup connectivity, I remember waiting 15-30 seconds for dial out + negotiation to occur before ping replies began flowing again.

Car: your car is an integrated system where all the components have been selected with the intent of working together as an integrated system. A display device often supports many modes and has very few guarantees about how sources will behave, thus inter-device negotiation is needed upon connection.

As other comments have noted, the control channel is fairly low bandwidth and there is potentially a decent sized chunk of info to exchange, plus timeouts and delays to ensure the display can work with older or less featured sources.

I have an Asus monitor, it has DVI, HDMI, VGA. The HDMI has a quirk, I forget what, so I use a HDMI to DVI cable to connect my laptop to it. And when I switch sources away from DVI, the laptop doesn't think the 2nd display disappeared. So I don't think there's a handshake being done when switching back, because they were holding hands the whole time.

I think the quirk was, if I have something plugged into the VGA input, and the HDMI input goes to powersave mode, the monitor "helpfully" says, "Oh, no HDMI signal? Let me switch sources!"

Although this is justification to why it’s terrible I don’t consider it an excuse of why it is terrible.

The amount of actual information transmitted there the handshake should be as close to what we perceive instant.

We know the cable can handle it because a modern desktop resolution at 60fps goes down the same cable.

but why does this need to happen every time, when the connected devices are basically static?

Reply on news.ycombinator.com