DisplayPort and HDMI §

The budget has only four levers, and every product decision about display links is one of them:

1. Fewer pixels (lower resolution or refresh) — what “dynamic resolution scaling” and reduced-blanking timings do.
2. Fewer bits per pixel — 8 bpc instead of 10, or 4:2:2/4:2:0 chroma subsampling (why “HDR on HDMI 2.0” often silently means 4:2:2).
3. More link bandwidth — more lanes, a faster link rate, or a more efficient line code.
4. Compression — DSC (see Compression), which is visually lossless and compresses roughly 3×, at the cost of a line-width latency of a few microseconds.

Because the stream is constant-rate, there is no “burst” trick: if the required rate exceeds the payload, the mode simply does not display (or the source silently falls back to one of the levers above — which is why a monitor sometimes drops to 30 Hz or 4:2:2 after you connect it with the wrong cable).

TMDS (Transition-Minimised Differential Signalling) sends each byte as a 10-bit symbol chosen to minimise signal transitions and balance DC — a scheme HDMI inherited from DVI (1999), which HDMI 1.0 (2002) extended with audio, CEC device control, and HDCP copy protection. The separate clock lane is the giveaway that this is a timed stream: the sink recovers the pixel clock from a dedicated pair and locks its refresh to it, so the line rate of each data lane is an exact multiple of the pixel clock.

HDMI 2.1’s Fixed Rate Link is a different philosophy: the link runs at a fixed rate decoupled from the pixel clock, and video timing is conveyed by the link structure itself. FRL does not do away with structure: the link still sends repeating training and alignment patterns, and the sink recovers video timing from the fixed-rate link clock together with the timing references carried in the packetised stream — the pixel clock is no longer the rhythm of the cable, but a derived quantity. This decoupling is what lets one fixed-rate link serve every video mode, and what lets DSC compress modes (8K60, 4K240) that would never fit uncompressed.

Sources: HDMI 2.1 specification (HDMI Licensing Administrator) · HDMI Forum specifications overview

DisplayPort was designed by VESA as a royalty-free, packetised successor to analog VGA and TMDS-era DVI. Packetisation is the key structural difference from HDMI 1.x: because the link carries packets rather than a raw pixel stream, it can

• multiplex several displays over one cable (MST) — the basis of most USB-C and Thunderbolt docks;
• tunnel cleanly inside Thunderbolt and USB4, which carry DisplayPort packets as one of their tunnel types — the reason docks speak DisplayPort and not HDMI;
• add metadata (HDR, adaptive sync) as new packet types without changing the pixel format.

Link training is the other signature mechanism. On connect, the source reads the sink’s capabilities over AUX, then sends test patterns while sweeping the PHY’s voltage swing and pre-emphasis levels until the receiver reports a clean eye. The link therefore adapts to the cable it actually finds — a short good cable trains at low swing, a long cheap cable forces maximum swing and pre-emphasis — instead of being designed for one worst case. Try it:

On a good cable the link locks at low swing immediately; on a long cheap cable it sweeps all swing levels and then all pre-emphasis levels before locking — which is exactly what you see in a DisplayPort debug log when a marginal cable “takes a while to come up”.

Sources: VESA DisplayPort standard (DP 1.4a and 2.1) · VESA Display Stream Compression (DSC)

The mux is why USB-C display behaviour is so confusing in practice. A USB-C port can run DP Alt Mode in 4-lane mode (all four SuperSpeed pairs carry DisplayPort; no USB 3 data) or 2-lane mode (two pairs carry DP, two carry USB 3). Which modes a port supports, and at which DP link rates, is a property of the specific laptop — not of the USB-C logo. And when the port is a Thunderbolt port, the DP traffic is tunnelled as packets inside the Thunderbolt link instead, which is why a Thunderbolt dock can drive two 4K displays and offer full USB bandwidth simultaneously, while a plain Alt-Mode dock must trade one against the other.

This is also why a “USB-C to HDMI” adapter can be passive (it only re-wires the connector when the port supports DP Alt Mode with an HDMI-conversion pin mapping) or needs an active converter chip (when the port has no Alt Mode at all, and the adapter must read pixels out of USB bandwidth).

HDCP is why a perfectly good cable can still give you a black screen. Each HDCP version has a bandwidth tier: HDCP 1.4 covers up to 4K30-class streams, and HDCP 2.2/2.3 is required for 4K HDR content. The negotiation happens over the link’s control path (AUX for DisplayPort, the CEC/SDA lines for HDMI) before video flows; if the sink’s receiver cannot authenticate at the required version, the source refuses to send protected content. This is a policy mechanism riding on the link, not a physics limit — which is why it fails in ways bandwidth arithmetic cannot explain.

Adaptive sync inverts the founding assumption of both links — a fixed, timed pixel rate. The source sends a special packet (DP) or signalling period (HDMI VRR) declaring the duration of the next frame, and the sink stretches or shrinks that frame’s scan-out instead of tearing or dropping to a fixed divisor of 60 Hz. The result: no stutter at frame rates that do not divide evenly into the refresh rate, and no tearing without a queue latency penalty. DisplayPort standardised it first (DP 1.2a Adaptive-Sync, the basis of FreeSync); HDMI 2.1 made VRR part of the FRL feature set.

VGA’s weakness was structural, not a matter of build quality: an analog voltage degrades along the cable — attenuation rolls off high frequencies (blurring sharp edges), impedance mismatches reflect energy back as ghosts, and noise adds directly to the pixel values — so image quality depended on cable length and quality, and the sink had to re-digitise a signal that had been digital inside the GPU. DVI, HDMI and DisplayPort digitise at the source and keep the signal digital end-to-end: the only degradation is bit errors, which a healthy link avoids entirely and a marginal one shows as isolated sparkles — never as blur. The same physics sets the analog limits (see Electromagnetism); digital coding plus link training simply buys the margin back.

DVI’s dual-link variant is the same lesson in bandwidth form: one TMDS link was not enough for the 30-inch monitors of 2004, so DVI simply doubled the data lanes — the same “more lanes” lever DisplayPort and HDMI FRL still pull today.

Sources: VESA DisplayPort standards (successor to DVI)

A laptop has one DisplayPort 1.4 output (HBR3, 25.92 Gb/s payload) and wants to drive two 4K60 displays, RGB 4:4:4 at 10 bpc, through an MST hub. Why does this fail, and which DisplayPort features address it?