3 ms·

> 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

> 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.

int0x2e 4y ago
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...
- wruza 4y ago
  Example EDID: https://edid.tv/edid/752/ 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.
- deleted 4y ago
  [deleted]

int0x2e 4y ago

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...

wruza 4y ago
Example EDID: https://edid.tv/edid/752/ 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.
deleted 4y ago
[deleted]