LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

HDMI vs DisplayPort: The Protocol War at the End of Your Cable

12 min read The Physics of Computing
hdmidisplayportvideohardwareconnectivitystandards
Contents

There are two connectors on the back of a modern graphics card, they carry the same pixels to the same monitors, and the choice between them is one of the most quietly consequential decisions in consumer hardware — not because one makes a better picture, but because each is the visible end of a completely different political and economic machine. HDMI was built by a consortium of television and movie-studio companies to move protected content into your living room, governed by a closed specification and a per-device royalty. DisplayPort was built by VESA, the PC monitor standards body, to be royalty-free and to replace the tangle of VGA and DVI inside and outside the computer. The two have spent twenty years converging on the same job — packetized digital audio and video over a few high-speed differential pairs — while diverging on everything around it: who is allowed to implement it, which features get priority, and which device category each one quietly won. The cable at the end of your device is chosen for you by that history, and understanding it explains every frustration from “why won’t this daisy-chain” to “why can’t my Linux box do 4K120 over HDMI.”

Two Origin Stories, Two Governance Models

HDMI arrived first, in 2002, from a founding group of consumer-electronics and content companies — Sony, Philips, Panasonic, Toshiba, Hitachi, and the chip company Silicon Image among them. Its DNA is Hollywood and the living room: from the very beginning it bundled digital audio and HDCP content protection, because its reason to exist was moving studio content onto televisions in a form the studios would bless. It is governed today by the HDMI Forum (which writes the spec) and the HDMI Licensing Administrator (which licenses it), the specification is closed to non-members, and every device that implements it pays a per-unit royalty plus logo fees. That model funded a vast ecosystem — essentially every TV, console, and AV receiver on earth speaks HDMI — but it is a toll road.

DisplayPort came in 2006 from VESA, the same standards body behind the monitor mounting holes and EDID. Its DNA is the PC: it was designed to replace VGA and DVI both as the internal panel link in laptops (as eDP) and as the external monitor connector. Critically, VESA made it royalty-free to implement for its members. DisplayPort’s job was never to please Hollywood; it was to give the PC industry an open, high-bandwidth, feature-rich pipe it did not have to pay a competitor to use. That single difference in governance — closed and royalty-bearing versus open and royalty-free — is the root cause of nearly every divergence that follows, including the one that bites Linux users hardest.

How the Pixels Actually Move

Both standards do fundamentally the same thing: serialize audio and video into packets and push them over a handful of high-speed differential lanes, with a slower side channel for control. The differences are in the link layer.

DisplayPort uses a micro-packet architecture over up to four lanes plus a low-speed AUX channel for link training, EDID, and control. Because the main link is packetized rather than tied to a pixel clock, DisplayPort can negotiate among a ladder of link rates and simply allocate however many packets a given resolution needs. The older rates — RBR, HBR, HBR2, HBR3 — use 8b/10b encoding, which spends 20% of the wire on encoding overhead. DisplayPort 2.0/2.1 introduced the UHBR rates (UHBR 10, 13.5, and 20) which switch to 128b/132b encoding, dropping the overhead to roughly 3%. That is why DisplayPort 2.1 at UHBR20 advertises 80 Gbps of raw link rate but delivers about 77.4 Gbps of actual data — a ~96.7% efficiency that HDMI’s encoding cannot match.

HDMI, for most of its life, used TMDS (transition-minimized differential signaling), where three data lanes were locked to a pixel clock — an architecture inherited from DVI and fundamentally analog-era in its thinking. HDMI 2.1 made the decisive break with FRL (Fixed Rate Link), which, like DisplayPort, decouples the lanes from the pixel clock and runs them at fixed rates across four lanes (FRL1 through FRL6, topping out at 48 Gbps). HDMI 2.2, finalized in mid-2025, pushes a next-generation FRL to 96 Gbps. In other words, HDMI 2.1’s headline feature was catching up to the packetized, fixed-rate architecture DisplayPort had used for fifteen years.

Both also lean on DSC — Display Stream Compression, a VESA standard providing roughly 3:1 “visually lossless” compression — to push resolutions past what the raw wire allows. The telling detail: DisplayPort 2.1 makes DSC support mandatory, while HDMI 2.1 leaves it optional, which is a microcosm of the two cultures — the PC standard mandates the capability, the TV standard leaves it to the manufacturer.

Standard Max raw bandwidth Link layer Encoding Typical ceiling (uncompressed)
HDMI 2.0 18 Gbps TMDS 8b/10b 4K @ 60 Hz
HDMI 2.1 48 Gbps FRL (4 lanes) 16b/18b 4K @ 120 Hz, 8K @ 60 Hz
HDMI 2.2 96 Gbps FRL next-gen 16b/18b 8K @ 60 Hz 4:4:4, up to 16K w/ DSC
DisplayPort 1.4 32.4 Gbps HBR3 (4 lanes) 8b/10b 4K @ 120 Hz, 8K @ 30 Hz
DisplayPort 2.1 80 Gbps UHBR20 (4 lanes) 128b/132b 4K @ 240 Hz, 8K @ 85 Hz

DisplayPort Daisy-Chains; HDMI Does Not

The packetized design gives DisplayPort a structural feature HDMI simply does not have in practice: MST, Multi-Stream Transport. Because the link carries independent packet streams, one DisplayPort output can drive several monitors routed through an MST hub or daisy-chained from one display to the next, the bandwidth divided among them. For a PC desk with three 1440p panels, that means one cable out of the GPU and a chain across the monitors. HDMI is, in normal use, strictly point-to-point — one source, one sink, one display per port.

  DisplayPort (MST)                        HDMI (point-to-point)
  ┌─────────┐                              ┌─────────┐
  │   GPU   │── one DP cable ──┐           │   GPU   │
  └─────────┘                  v           └────┬────┘
                          ┌─────────┐           │ one cable per display
                          │ Mon 1   │──┐        ├──────────► Display A
                          │ (DP-out)│  │        ├──────────► Display B
                          └─────────┘  │        └──────────► Display C
                                       v        (3 ports, 3 cables, no chaining)
                          ┌─────────┐
                          │ Mon 2   │──┐
                          └─────────┘  v
                          ┌─────────┐
                          │ Mon 3   │
                          └─────────┘
       bandwidth shared across the chain; one GPU port total

This single capability is why DisplayPort dominates the multi-monitor PC world and why docking stations lean on it. It is also why DisplayPort is the protocol that rides over USB-C: DP Alt Mode maps DisplayPort lanes directly onto the USB-C connector, and that same DisplayPort stream is what gets tunneled across Thunderbolt and USB4. There is an HDMI Alt Mode for USB-C on paper, but it never shipped in any meaningful volume — so the universal connector of the laptop era speaks DisplayPort natively and reaches HDMI only through an adapter. That is a structural, long-term advantage for DisplayPort in everything portable.

HDMI Owns the Living Room

If DisplayPort won the desk, HDMI decisively won the den, and not by accident — its entire feature set is built around the television and AV stack. The features that matter there are ones DisplayPort never prioritized:

  • eARC (Enhanced Audio Return Channel) sends high-bitrate audio back from the TV to a soundbar or AV receiver over the same cable, carrying lossless Dolby TrueHD and DTS:X. This is the backbone of modern home theater and has no DisplayPort equivalent.
  • CEC (Consumer Electronics Control) lets one remote power and switch a whole chain of devices — the reason your TV remote can control the soundbar and the console.
  • VRR, ALLM, and QFT — variable refresh rate, auto low-latency mode, and quick frame transport — are the gaming-TV and console features that made HDMI 2.1 matter for the PlayStation and Xbox generation.
  • Dynamic HDR metadata for formats like Dolby Vision.

DisplayPort has its own equivalents where they overlap — Adaptive-Sync, the open VESA variable-refresh standard, is the basis of AMD FreeSync and the broader VRR ecosystem on monitors — but it has nothing for the audio-return and one-remote problems because those are living-room concerns, not desk concerns. The result is a clean split: TVs, consoles, and AV receivers are an HDMI world; PC monitors, GPUs, and docks are a DisplayPort world, and the overlap in the middle is served by adapters. The choice of cable at the end of any given device is, more than anything, a statement about which of those two worlds the device was designed for. The trade-offs in the panel itself and the TV display technologies are downstream of which connector the device speaks.

The Open-Source Fault Line

Here the governance difference stops being abstract and starts costing people features. In 2024 the HDMI Forum rejected AMD’s request to implement HDMI 2.1 in its open-source Linux graphics driver. The reasoning traces directly to the closed, licensed model: the HDMI Forum does not permit the protocol’s details to appear in open code that anyone can read, because that would expose the licensed specification. The practical consequence is concrete and current: on a Linux machine using the open amdgpu driver, you cannot get HDMI 2.1 features — 4K at 120 Hz, the higher FRL rates — over an HDMI port. The workaround the Linux community universally recommends is to use DisplayPort instead, because DisplayPort is royalty-free and openly specified, so its full feature set lives happily in open drivers.

For a homelab, a self-hosted workstation, or anyone running open graphics drivers, this is not a footnote — it is a buying criterion. It means the open standard is not merely philosophically nicer; it is the one that actually works at full capability on an open stack. The closed model that funded HDMI’s ubiquity is the same model that fences it out of the open ecosystem, and that tension is unlikely to resolve soon. There are partial escape hatches — an external DisplayPort-to-HDMI converter chip handles the protocol translation in hardware, outside the driver, so a DP output can still feed an HDMI TV at high rates — but that is a workaround layered on top of the problem, not a fix for it. If your workflow lives on open drivers, the cleanest answer is to keep the whole path DisplayPort wherever the display will allow it, and treat HDMI as the fallback for the devices that only speak it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Inspect what your outputs and cables actually negotiated (Linux)
# List connectors and their current modes
for c in /sys/class/drm/card*-*/; do
  echo "$(basename "$c"): $(cat "$c/status")"
done

# Detailed mode and link info via libdrm tools
modetest -c                      # connectors, encoders, modes
modetest -p                      # planes

# Decode the monitor's EDID (capabilities the display advertises)
edid-decode < /sys/class/drm/card1-DP-1/edid

# Check the negotiated DisplayPort link rate and lane count
cat /sys/kernel/debug/dri/0/DP-1/i915_dp_mst_info 2>/dev/null
xrandr --verbose | grep -A2 "connected"

Cables, Versions, and the Labeling Lie

As with the high-speed signaling reality of any modern link, the cable is now an active participant, and the labels are a minefield. Both ecosystems pin their highest speeds to certified cables: HDMI’s top tier is the Ultra High Speed cable (48 Gbps) and now the Ultra96 cable (96 Gbps for HDMI 2.2); DisplayPort’s is the DP80 (UHBR20) certification. A cable below the required tier silently negotiates down, dropping your 4K120 to 4K60 with no error message — the same lowest-common-denominator failure mode that plagues USB-C.

The version-number trap is worse on the HDMI side, where the Forum permits manufacturers to label a port “HDMI 2.1” even if it implements none of 2.1’s distinguishing features, because the older versions were folded into the 2.1 spec as optional. A port marked “HDMI 2.1” might do 48 Gbps or might do a bare 18 Gbps; you have to read the supported features, not the version. DisplayPort’s UHBR tiers (UHBR10/13.5/20) are at least more honest about what speed is guaranteed. The defensive habit for both: ignore the version number, look up the actual bandwidth tier and feature list, and buy a properly certified cable for the speed you need.

Need Better choice Why
TV, console, AV receiver, home theater HDMI eARC, CEC, ALLM; universal on TVs and consoles
PC monitor, high refresh, multi-monitor DisplayPort MST daisy-chaining, higher efficient bandwidth, Adaptive-Sync
Laptop / USB-C / dock DisplayPort (Alt Mode) Native over USB-C and Thunderbolt; HDMI needs an adapter
Open-source Linux graphics driver DisplayPort HDMI 2.1 features are blocked in open drivers
Single 8K / extreme uncompressed HDMI 2.2 (96 Gbps) or DP2.1 + DSC Raw bandwidth ceiling vs mandatory compression

Verdict

HDMI and DisplayPort make indistinguishable pictures, and choosing between them is really choosing between two governance philosophies and the device ecosystems they produced. HDMI is the closed, royalty-bearing, Hollywood-descended standard that owns the television, the console, and the AV receiver, with eARC, CEC, and a feature set tuned for the living room — and it pays for that ubiquity with a licensing model so closed it cannot legally appear in open-source Linux drivers, which is why HDMI 2.1’s best features are unreachable on an open amdgpu stack. DisplayPort is VESA’s royalty-free, PC-descended standard that owns the monitor and the GPU, with more efficient 128b/132b encoding, mandatory DSC, MST daisy-chaining, and native carriage over USB-C and Thunderbolt — the structural reason it dominates everything portable and everything open. The practical rules fall out cleanly: HDMI for anything that plugs into a TV, DisplayPort for anything that plugs into a monitor, DisplayPort especially if you run open graphics drivers or want to daisy-chain displays, and a properly certified cable in either case because the labels lie and an undersized cable fails silently. The war at the end of your cable was never about pixels. It was about who controls the wire — and on that question, the two camps gave permanently different answers.

Sources

Comments