HDMI and DisplayPort Explained: TMDS, FRL, EDID, CEC and HDCP

HDMI and DisplayPort are digital display links with two layers. A fast layer carries pixels and audio: TMDS or Fixed Rate Link (FRL) lanes on HDMI, packetised main link lanes on DisplayPort. A slow layer carries everything else: EDID tells the computer what the screen supports, CEC (HDMI) and the AUX channel (DisplayPort) carry control messages, and HDCP authenticates devices and encrypts protected content.

HDMI is specified by the HDMI Forum and licensed through HDMI Licensing Administrator. DisplayPort is specified by VESA, the Video Electronics Standards Association. This guide goes one level deeper than our posts on USB and Thunderbolt and DMA attacks, charging ports and USB Power Delivery and how a smart TV is made. We worked from hdmi.org, VESA's press releases and displayport.org, the HDCP specifications published by Digital Content Protection LLC, and the Linux kernel documentation (docs.kernel.org, version 7.3.0).

Key takeaways

• HDMI 2.2 is the current HDMI specification: announced 6 January 2025, released 25 June 2025, up to 96 Gbps with a next generation Fixed Rate Link, and it needs the Ultra96 HDMI Cable for full bandwidth.
• HDMI 2.1 (November 2017) tops out at 48 Gbps over the Ultra High Speed HDMI Cable.
• DisplayPort 2.1 (17 October 2022) runs four lanes at up to 20 Gbps each (UHBR20) with 128b/132b coding, mandates Display Stream Compression (DSC) support and aligns its physical layer with USB4.
• DisplayPort Alt Mode carries DisplayPort over USB Type-C. Alt Mode 2.0 (April 2020) allows up to 80 Gbps of video on all four lanes, or 40 Gbps alongside SuperSpeed USB data.
• EDID is untrusted input to the graphics driver. The Linux kernel has fixed several EDID and DisplayID parsing bugs, including out of bounds reads.
• CEC is an unauthenticated, very slow control bus on HDMI that can switch inputs and power devices off. DisplayPort's AUX channel carries configuration registers, EDID reads and can tunnel CEC.
• HDCP 1.4 uses a linear key scheme; HDCP 2.x uses RSA certificates, AES 128 and a 20 ms locality check. HDCP protects licensed content, not your data.
• Monitor scalers, TV systems on chip, docks, MST hubs and retimers all run firmware with their own update paths. Docks are the easiest to forget.

Who defines HDMI and DisplayPort?

HDMI: the HDMI Forum and HDMI Licensing Administrator

The HDMI Forum, Inc. writes the specification; according to hdmi.org its Technical Working Group developed HDMI 2.2, and the Forum is an open trade association of more than 90 companies. HDMI Licensing Administrator, Inc. (HDMI LA) is the agent the Forum appointed to license version 2.2, and the agent the HDMI Founders appointed for earlier versions.

The specifications go to licensed adopters. hdmi.org offers only HDMI 1.3a, and the 3D portion of HDMI 1.4b, for public download, so most public knowledge of newer HDMI internals comes from hdmi.org summaries and open source driver code. hdmi.org says almost 14 billion HDMI devices have shipped since the first specification in December 2002.

DisplayPort: VESA and the DisplayPort Task Group

DisplayPort belongs to VESA, a non profit association of more than 300 member companies. Its DisplayPort Task Group develops the specifications and runs compliance and branding. VESA also owns E-EDID, DisplayID, DDC/CI and the Monitor Control Command Set (MCCS), so a computer reading a monitor's capabilities over HDMI is usually parsing a VESA data structure on an HDMI Forum link, plus a CTA-861 extension block describing TV video formats.

How have the versions evolved?

The table lists versions whose dates and figures we confirmed on a primary source.

DisplayPort moved earlier to compression and very high per lane rates; HDMI's big jump came with FRL in HDMI 2.1, extended in 2.2. A version number on a box does not tell you which features a product implements, which is why hdmi.org introduced the Ultra96 feature name to show which products need the 96 Gbps cable.

How do the physical links work?

HDMI with TMDS: three colour channels and a clock

HDMI inherited its original signalling from DVI. Transition Minimized Differential Signalling (TMDS) sends video over three differential data pairs, one per colour component in the simplest RGB case, plus a separate clock pair. Each 8 bit value is encoded into a 10 bit symbol chosen to reduce transitions on the wire and keep the DC balance of the signal. Between lines and frames, the link carries "data islands" with audio samples and InfoFrames, which are small packets that describe the colour space, aspect ratio, HDR metadata and similar settings. The HDCP 1.4 specification's terminology section refers to these HDMI structures (data island period, guard bands, video data period) because HDCP encrypts the data within them.

Because the data rate tracks the pixel clock, TMDS bandwidth scales with resolution and refresh rate until it hits a ceiling. HDMI 1.4b, which hdmi.org describes as supporting 4K and 1080p at 120 Hz, also defined the HDMI Ethernet Channel and the Audio Return Channel (ARC), which sends TV audio back upstream to a receiver or soundbar.

HDMI with FRL: fixed rate lanes and packetised data

HDMI 2.1 introduced Fixed Rate Link. Instead of tying the line rate to the pixel clock, FRL runs the lanes at fixed rates and packs video, audio and auxiliary data into packets, with the old clock pair repurposed as a fourth data lane. A link training step lets source and sink agree on the highest rate the cable and devices can sustain. This is the change that made 48 Gbps possible on HDMI 2.1 and it is also what made compression (DSC) workable on HDMI, since compressed data does not map neatly to a pixel clock.

HDMI 2.2 keeps the same architecture and calls it "next-gen HDMI Fixed Rate Link". hdmi.org lists the headline results: up to 96 Gbps, uncompressed full chroma formats such as 8K at 60 Hz and 4K at 240 Hz in 4:4:4 at 10 and 12 bit colour, and support for 10K, 12K and 16K resolutions (12K at 120 Hz and 16K at 60 Hz). HDMI 2.2 also adds a Latency Indication Protocol (LIP) to keep audio and video in sync across chains with a receiver or soundbar in the middle.

The cable matters more with FRL. According to hdmi.org, the Ultra High Speed HDMI Cable covers up to 48 Gbps, the Ultra96 HDMI Cable is the only one that supports all HDMI 2.2 applications, and products marketed with the Ultra96 name (64, 80 or 96 Gbps) need it for full bandwidth. Both must pass certification at an HDMI Forum Authorized Testing Center and carry a QR scannable label.

DisplayPort: a packetised main link plus an AUX channel

VESA's DisplayPort 1.4 release calls DisplayPort "a packet-based, extensible protocol for transporting video and audio data." The main link has one, two or four lanes with no separate clock pair; the receiver recovers the clock from the data, and video, audio and secondary packets share the lanes.

Earlier DisplayPort versions use 8b/10b coding. VESA gives the arithmetic for DP 1.3 and 1.4: four lanes at 8.1 Gbps per lane is 32.4 Gbps of link bandwidth, and after 8b/10b coding that is a maximum payload of 25.92 Gbps. DisplayPort 2.0 raised the per lane rate to up to 20 Gbps and switched to 128b/132b coding, which wastes far less of the line rate, for a maximum payload of 77.37 Gbps. VESA's Alt Mode 2.0 release gives the per lane payload as up to 19.34 Gbps. The new rates are called UHBR10, UHBR13.5 and UHBR20.

Beside the main link sits the AUX channel, a slower bidirectional channel for the sink's DisplayPort Configuration Data (DPCD) registers, EDID reads (I2C over AUX) and sideband messages. Link training happens over AUX: the source reads the sink's capabilities, sets a rate and lane count, sends training patterns and reads status until the link locks or falls back to a lower rate.

DisplayPort also has Multi-Stream Transport (MST), which multiplexes several display streams onto one link so a single port can drive several monitors through a hub or daisy chained displays. displayport.org notes that MST is enabled by default beginning with the DisplayPort 2.x generation.

Display Stream Compression

DSC is VESA's "visually lossless" compression codec. VESA introduced it in April 2014 and DP 1.4 was the first DisplayPort version to use it, with DSC 1.2 enabling up to 3:1 compression. DisplayPort 2.1 mandates DSC support, and VESA says DSC bitstream support can reduce DisplayPort transport bandwidth by more than 67 percent. HDMI also supports DSC from version 2.1 onward; the kernel's KMS documentation includes a structure that "describes the DSC support provided by HDMI 2.1 sink", including the maximum FRL rate per lane with DSC. Compression is why two setups that both "work" can differ: one may be running uncompressed, the other compressed.

DisplayPort Alt Mode over USB-C and tunnelling over USB4

USB Type-C connectors have four high speed differential pairs. In DisplayPort Alt Mode, the USB-C port negotiates with the device on the other end (through USB Power Delivery messages on the configuration channel) and hands some or all of those pairs to DisplayPort. VESA's Alt Mode 2.0 announcement states that the USB-C connector can carry up to 80 Gbps of DisplayPort video using all four lanes, or up to 40 Gbps while still carrying SuperSpeed USB data on the others.

USB4 and Thunderbolt add a second model: tunnelling. Instead of handing raw pairs to DisplayPort, the host wraps DisplayPort traffic in USB4 packets alongside PCI Express and USB traffic. VESA says DisplayPort 2.1 tightened alignment with the USB4 PHY so that one physical layer serves both, and added a bandwidth management feature so tunnelled DisplayPort can coexist with other I/O. hdmi.org also lists an HDMI Alt Mode for USB Type-C, which carries native HDMI 1.4b signals over a USB-C cable, though most USB-C video in practice is DisplayPort, with a converter chip in the dongle or monitor when an HDMI output is needed. Those converters are called protocol converters (PCONs), and the Linux kernel has helpers that drive them over the AUX channel, including preparing a PCON for FRL and choosing between concurrent and sequential FRL training with the HDMI sink.

What is EDID, and how does a source learn what a monitor supports?

The structure

EDID (Extended Display Identification Data) is a block of bytes stored in the display, traditionally in a small EEPROM on the DDC lines of the connector. The base block is 128 bytes. It carries a fixed header, the manufacturer and product codes, a serial number, the week and year of manufacture, the EDID version, basic display parameters, colour characteristics, established and standard timings, and four 18 byte descriptors that hold the preferred detailed timing, the monitor name and range limits. Byte 126 (0x7E) holds the number of extension blocks that follow, and the last byte of each block is a checksum.

Extension blocks add everything modern displays need. The CTA-861 extension lists video formats by Video Identification Code (VIC), audio formats, speaker allocation, HDR static metadata and vendor specific data blocks, including the HDMI vendor blocks that advertise maximum TMDS rate, FRL rates and DSC support. DisplayID, also a VESA standard, is a newer, more flexible structure that can appear either as an EDID extension or on its own, and it is common on tiled and very high resolution displays.

The edid-decode manual lists the timing formats a parser must handle: VESA DMT, CVT and GTF timings, old IBM and Apple timings, CTA-861 and HDMI VICs, detailed timing descriptors, DisplayID timing modes and CTA-861.6 video format descriptors.

How the source reads it

On HDMI and DVI, the source reads EDID over DDC, which is an I2C bus on two pins of the connector, at the standard address 0x50, with a segment pointer at 0x30 for EDIDs longer than 256 bytes. On DisplayPort, the same I2C transactions are carried as I2C over AUX. Hot plug detect, a dedicated pin, tells the source that something was connected or that the sink wants attention, and the source then re-reads the EDID.

The Linux kernel exposes the result in sysfs. The edid-decode manual notes that "EDID blocks for connected monitors can be found in /sys/class/drm/*/edid" on systems with kernel modesetting. The kernel's DRM helpers include functions to read and validate an EDID; the documentation for drm_edid_valid says it will "cross check block count against allocated size and checksum the blocks."

Why malformed EDIDs are a parsing risk

To the driver, EDID is external input. A monitor, KVM switch, capture card, cheap adapter or test device can present any bytes it likes, including the extension count and every length field. Code that trusts a length and reads past its buffer has a memory safety bug. Dated examples from the National Vulnerability Database, each described in its kernel fix:

None needed anything exotic: wrong lengths in a few bytes delivered over a cable or a virtual device. For parser authors the lesson is to validate lengths against the buffer you hold, not the length the data claims, and to fuzz with malformed blocks. For operators: kernel and driver updates that mention EDID or DisplayID are worth taking.

Overriding a bad EDID

The kernel's EDID admin guide lists why EDID goes wrong, from monitors that send bogus data to cases where "a KVM sends its own EDID data instead of querying the connected monitor." The fix is a corrected EDID loaded from /lib/firmware (the CONFIG_DRM_LOAD_EDID_FIRMWARE option and the drm.edid_firmware parameter). Keep that file in version control like any configuration the kernel trusts.

What are HDMI CEC and the DisplayPort AUX channel, and what can devices tell each other?

CEC: a shared remote control bus

Consumer Electronics Control is a single wire bus that runs through every HDMI cable in a chain. The kernel's CEC documentation explains that HDMI connectors "provide a single pin" for it, that CEC 1.4 is defined in supplements to HDMI 1.4a and CEC 2.0 extensions in chapter 11 of HDMI 2.0, and that the bitrate is "effectively no more than 36 bytes per second", based on the AV.link protocol from old SCART connectors.

Each device claims a logical address from 0 to 15 (0 is the TV) and has a physical address such as 1.0.0.0 that reflects its place in the HDMI tree. In practice CEC lets devices wake the TV and switch it to their input, put the chain into standby, pass remote control key presses, report names, vendor IDs and power status, and control audio system volume.

That is a lot of power for a bus with no authentication. Anything that can run code on an HDMI connected device (a streaming stick, a meeting room PC, a signage player) can switch inputs or power off a screen that others depend on.

The DisplayPort AUX channel

The AUX channel is DisplayPort's control path, and it is more capable than CEC. The source uses it to read the sink's DPCD registers: capability bytes at the start of the address space (DPCD revision at 0x000, maximum link rate at 0x001, maximum lane count at 0x002, according to the kernel's drm_dp.h header), link configuration registers it writes during training (0x100 for the link rate, 0x101 for the lane count) and status registers it reads back. AUX carries EDID reads as I2C over AUX, MST sideband messages that discover and configure hubs and downstream monitors, HDCP authentication messages on DisplayPort and, on sinks that support it, CEC tunnelled over AUX. The kernel's drm_dp_aux structure includes a CEC adapter field for "CEC-Tunneling-over-AUX support".

A sink answers register reads and can request attention through hot plug interrupts; a source can write sink registers. Monitor control over DDC/CI (brightness, input and other MCCS settings) rides the same I2C path on HDMI and DisplayPort. None of this reaches the computer's memory: unlike PCI Express tunnelling over Thunderbolt or USB4, a display link gives the far end no direct memory access. The risk is narrower, namely confusing or crashing the driver that parses what the far end says.

Where Linux exposes these channels

CEC adapters appear as /dev/cecX, driven by the v4l-utils tools cec-ctl, cec-compliance and cec-follower. AUX channels appear as /dev/drm_dp_auxN when the kernel is built with CONFIG_DRM_DISPLAY_DP_AUX_CHARDEV, whose help text says it allows reading and writing "arbitrary DPCD registers".

What does HDCP do, and where are its limits?

Purpose and owner

High-bandwidth Digital Content Protection is a copy protection system for the link between a source and a display. Digital Content Protection LLC, which licenses it, describes HDCP as a specification "developed by Intel Corporation" to protect motion pictures, TV and audio "against unauthorized interception and copying" between devices. The specifications are published on digital-cp.com, which lists HDCP 1.4 (8 July 2009), HDCP 2.2 interface independent adaptation (16 October 2012), HDCP 2.3 on HDMI (28 February 2018) and HDCP 2.3 on DisplayPort (23 January 2019), among others.

HDCP 1.4: a linear key scheme

Under HDCP 1.4, every device holds 40 secret 56 bit device keys and a 40 bit public Key Selection Vector (KSV). A valid KSV contains exactly 20 ones and 20 zeros. To authenticate, the transmitter and receiver exchange KSVs. Each side then adds up its own secret keys at the positions where the other side's KSV has a 1 bit, using 56 bit addition. If both hold genuine keys issued by the licensor, the two sums match and become the shared secret Km, which seeds the HDCP cipher. The transmitter checks the receiver's KSV against a revocation list, called the System Renewability Message (SRM), before continuing. After authentication, the link is encrypted with a stream cipher, and both sides compare a running check value every 128 frames to confirm they are still in sync.

The 1.4 system supports repeaters, such as AV receivers and splitters, that decrypt and re-encrypt for downstream displays. The spec allows up to seven levels of repeaters and up to 128 devices on one protected port.

The design limit is in the key scheme itself. Because every shared secret is a linear combination of keys derived from a hidden master matrix, enough device key sets let someone solve for the matrix and generate valid keys for any KSV. Cryptographers noted this weakness early, and in September 2010 what was reported to be the HDCP master key was posted publicly. We could not fetch a primary statement from the licensor about that event, so treat its details as reported rather than confirmed. Revocation through SRMs cannot fix that weakness, because keys generated from the master matrix can be fresh.

HDCP 2.x: public key authentication

HDCP 2.x is a different protocol. According to the HDCP 2.3 on HDMI specification:

• Every transmitter holds the 3072 bit RSA public key of DCP LLC, and every receiver holds a certificate signed by DCP LLC that contains its Receiver ID and a 1024 bit RSA public key.
• During Authentication and Key Exchange (AKE), the transmitter verifies the receiver's certificate, generates a 128 bit master key and sends it encrypted to the receiver's public key with RSAES-OAEP. A pairing step lets the receiver store the master key for faster re-authentication.
• A locality check requires the round trip time between a pair of messages to be no more than 20 ms, which is meant to stop content from being relayed far away.
• Session keys are 128 bits and the cipher is built on AES 128 in counter mode.
• The transmitter verifies the signature on the SRM using the DCP LLC public key before trusting it.
• Topology is tighter: up to four levels of repeaters and 32 devices in total.

HDCP 2.2 and later also define content types. Type 0 content may pass through HDCP 1.4 devices downstream; Type 1 content (typically the highest resolution streams) may only go to HDCP 2.2 or later devices. The Linux kernel exposes this as two connector properties, "Content Protection" with states Undesired, Desired and Enabled, and "HDCP Content Type" with Type0 and Type1. The kernel documentation notes that only the driver can set the property to Enabled, and that user space has to watch for the value dropping back to Desired, which "signifies the link is no longer protected."

What HDCP does not do

HDCP protects content owners, not you. It does not protect the computer from a malicious display or prove who owns a monitor, and desktop content such as a spreadsheet on a meeting room screen usually travels without it. Its practical limits are familiar: authentication failures through older receivers and splitters cause blank screens, and Type 1 content refuses to play through HDCP 1.4 equipment.

Where does firmware live in a display chain, and how is it updated?

A display chain is a series of small computers, each running firmware:

VESA's DisplayPort 2.1 release names the same categories when describing certification: GPUs, "docking station chips, monitor scalar chips, PHY repeater chips such as re-timers," and cables. On Linux, docks and many peripherals update through fwupd and the Linux Vendor Firmware Service (LVFS), which its documentation describes as a secure web service for OEM firmware uploads and update metadata. The same documentation names the core problem: users often do not know what hardware they have, its firmware version, or whether it can be updated. Monitors and TVs usually rely on their maker's own tool or over the air service.

How do HDMI and DisplayPort compare?

The content protection row is typical practice; HDCP is licensed separately and varies by product. The DP40, DP80 and DP80LL cable names come from VESA's press materials and displayport.org; the forthcoming DisplayPort 2.1b update introduces the DP80LL low loss active cable for four lane UHBR20 up to three metres, according to displayport.org.

Step by step: read EDID, check the link and list CEC devices on Linux

The commands below are read only unless a step says otherwise. They were written for a current Linux distribution with kernel modesetting. Package names are for Debian and Ubuntu; other distributions use similar names.

1. Install the tools

sudo apt install edid-decode v4l-utils read-edid libdrm-tests

edid-decode decodes EDID blocks, v4l-utils provides cec-ctl and friends, and libdrm-tests provides modetest for listing connectors and modes.

2. List the display connectors the kernel knows about

for c in /sys/class/drm/card*-*; do
  printf '%-28s %-14s %s\n' "$(basename "$c")" \
    "$(cat "$c/status" 2>/dev/null)" \
    "$(cat "$c/enabled" 2>/dev/null)"
done

Names such as card1-HDMI-A-1 and card1-DP-2 show the connector type the GPU drives; a USB-C port shows up as DP.

3. Dump and decode the EDID

CONN=card1-DP-2            # pick a connected connector from step 2
ls -l /sys/class/drm/$CONN/edid
edid-decode /sys/class/drm/$CONN/edid | less

Look for the manufacturer and serial number, the EDID version and extension count, the preferred detailed timing, the CTA-861 block with the HDMI vendor data blocks (maximum TMDS and FRL rates, DSC support), any DisplayID extension, and the conformance warnings edid-decode prints at the end.

To keep a copy for comparison or for a support ticket:

cp /sys/class/drm/$CONN/edid ~/edid-$(date +%F)-$CONN.bin
sha256sum ~/edid-*.bin

Comparing EDID hashes before and after you insert a dock, KVM or adapter tells you whether that device is passing through the monitor's EDID or substituting its own.

4. See which modes the kernel accepted

cat /sys/class/drm/$CONN/modes
modetest -c 2>/dev/null | less

modetest -c lists connectors with modes and properties such as "link-status", "Content Protection" and "HDCP Content Type". A mode in the EDID but missing here was rejected by the driver, often because the negotiated link cannot carry it.

5. Check the DisplayPort link rate and lane count

The negotiated link rate and lane count live in the sink's DPCD registers. If your kernel exposes AUX character devices, you can read them without changing anything:

ls -l /dev/drm_dp_aux*
# Read the first 16 bytes of DPCD (capabilities). This only reads.
sudo dd if=/dev/drm_dp_aux0 bs=1 count=16 status=none | xxd
# Read the link configuration the source set (0x100 rate, 0x101 lane count).
sudo dd if=/dev/drm_dp_aux0 bs=1 skip=256 count=2 status=none | xxd

In the capability bytes, offset 0x001 is the maximum link rate code and 0x002 holds the maximum lane count in its low bits. The rate codes defined in the kernel's drm_dp.h are 0x06 for 1.62 Gbps, 0x0a for 2.7 Gbps, 0x14 for 5.4 Gbps and 0x1e for 8.1 Gbps per lane. UHBR rates are reported separately: drm_dp.h defines bit 1 of 0x006 as 128b/132b support and register 0x2215 as the supported UHBR rates (bit 0 UHBR10, bit 1 UHBR20, bit 2 UHBR13.5). Do not write to these device files: writing DPCD registers changes the link and can leave a display blank until you reconnect it.

Many drivers also report the link in debugfs. The file names are driver specific, so search rather than guess:

sudo ls /sys/kernel/debug/dri/*/
sudo grep -ril "link" /sys/kernel/debug/dri/*/ 2>/dev/null | head

6. List CEC devices on an HDMI chain

ls -l /dev/cec*
cec-ctl -d0 --playback -S

As the cec-ctl manual explains, --playback describes your own device, not the one you talk to, and -S shows the topology: logical and physical addresses, vendor IDs and names of other devices. cec-ctl -A lists all CEC adapters.

To watch traffic without sending anything after the initial configuration:

cec-ctl -d0 --monitor

Control commands such as cec-ctl -d0 --to 0 --standby affect everyone using the display.

7. If the EDID is wrong, override it deliberately

If the monitor or a KVM is sending bad data, you can load a known good EDID that you captured earlier:

sudo mkdir -p /lib/firmware/edid
sudo cp ~/edid-known-good.bin /lib/firmware/edid/monitor.bin
# Then add this to the kernel command line (example connector name):
#   drm.edid_firmware=DP-2:edid/monitor.bin

On many distributions the file also has to be included in the initramfs. Record what you changed and why, because an override hides future changes in the real monitor's EDID.

A worked example: why a 4K 144 Hz monitor only offers 60 Hz

A monitor's EDID advertises 3840 by 2160 at 144 Hz, but through a USB-C dock the desktop offers only 60 Hz.

1. Hash the EDID direct and through the dock. Different hashes mean the dock substitutes or edits it.
2. Check the trained link. Four lanes at 5.4 Gbps carry 21.6 Gbps of line rate, about 17.28 Gbps of payload after 8b/10b coding.
3. Estimate the requirement. 3840 by 2160 at 144 Hz with 10 bit colour is about 1.19 billion pixels per second before blanking, times 30 bits, or roughly 35.8 Gbps. That needs DSC on a link of that size, or a faster link.
4. Check whether the dock and monitor both advertise DSC in the DPCD and EDID. If one does not, the driver falls back to the highest mode that fits uncompressed, which may be 60 Hz.
5. Check the dock's firmware version. Docks frequently add or fix DSC and HBR3 support in firmware updates.

The GPU was never the problem. The answer was in the EDID, the DPCD and the dock firmware.

Where does the security risk actually sit?

Ranked honestly, the risks are: driver parsing bugs in EDID, DisplayID, DPCD and MST handling (a real, recurring bug class fixed by updating kernels and drivers); CEC control of shared displays (an availability and nuisance risk in meeting rooms and lobbies); firmware in docks, KVMs and monitors, where docks matter most because they also sit on USB and network paths; and minor information leakage, since EDID serial numbers identify monitors. HDCP's weaknesses mostly affect content owners, not your organisation's data.

What a pure HDMI or DisplayPort link does not give the far end is direct memory access. That comes with PCI Express tunnelling over Thunderbolt and USB4, which our USB and Thunderbolt post covers. The display link carries pixels out and small control messages both ways.

Common mistakes

• Assuming any cable carries full bandwidth. A cable labelled "HDMI" or "4K" may be rated for far less than 48 Gbps. Look for the Ultra High Speed HDMI Cable label for HDMI 2.1 rates, the Ultra96 HDMI Cable for HDMI 2.2's full rate, and DP40 or DP80 certification for DisplayPort 2.1. Then check the negotiated link rate.
• Blaming the GPU for an EDID problem. Blank screens and missing refresh rates often come from an EDID that a dock, KVM or adapter substituted or corrupted. Decode and compare the EDID before reinstalling drivers.
• Leaving CEC control enabled on shared displays. In meeting rooms, lobbies and classrooms any connected device can switch inputs or turn the screen off. Disable CEC where it is not needed, or block it on guest inputs.
• Ignoring dock firmware updates. Docks hold PD controllers, USB hubs, MST hubs and converters, and many display fixes ship only as dock firmware. Inventory docks the way you inventory laptops.
• Using untrusted EDID override files. An override is data the kernel trusts. Load only files you captured from your own equipment and reviewed.
• Treating HDCP as link encryption for your data. Desktop content usually travels unprotected, and HDCP does not prove a display belongs to you.
• Mixing up USB-C cables and adapters. A USB 2.0 only USB-C cable has no high speed pairs for DisplayPort, and the HDMI version printed on a USB-C adapter describes its converter chip, not the laptop.

FAQ

What is the difference between HDMI and DisplayPort?

HDMI comes from the HDMI Forum, dominates TVs and adds CEC and ARC. DisplayPort is VESA's packet protocol with an AUX channel, Multi-Stream Transport and native USB-C support. HDMI 2.2 reaches 96 Gbps; DisplayPort 2.1 reaches 80 Gbps.

What is the difference between TMDS and FRL in HDMI?

TMDS sends data on three channels with a separate clock and ties the data rate to the pixel clock. FRL, introduced in HDMI 2.1, runs the lanes at fixed rates, packetises the data and uses the old clock pair as a fourth data lane. FRL is what allows 48 Gbps in HDMI 2.1 and 96 Gbps in HDMI 2.2.

How do I read my monitor's EDID on Linux?

Find the connector under /sys/class/drm/, then run edid-decode /sys/class/drm/card1-DP-2/edid with your connector name. The raw file is the EDID exactly as the kernel read it, so you can also copy it and hash it to compare later.

Can a monitor or HDMI cable hack my computer?

A display link gives the far end no direct memory access. The realistic risk is a driver bug triggered by malformed EDID or DisplayPort data, which the Linux kernel has fixed several times, so keep graphics drivers current.

What does HDCP 2.3 do that HDCP 1.4 does not?

HDCP 2.x replaced HDCP 1.4's linear key scheme with RSA certificates signed by DCP LLC, a 128 bit master key exchange, AES 128 encryption and a 20 ms locality check. It also adds content types, so the most protected content can be restricted to HDCP 2.2 or later devices.

What is HDMI CEC and should I turn it off?

CEC lets HDMI devices control each other: power on, input switching, standby and remote key pass through. It is convenient at home. On shared displays such as meeting rooms or signage, turn it off or restrict it, because any connected device can control the screen.

Does USB-C carry DisplayPort or HDMI?

Usually DisplayPort, through DisplayPort Alt Mode or tunnelled over USB4 and Thunderbolt. An HDMI Alt Mode for USB-C exists and carries HDMI 1.4b signals, but most USB-C to HDMI adapters contain a DisplayPort to HDMI converter.

Why does my monitor only run at 60 Hz over a dock?

The usual causes are a link trained at a lower rate than expected, a missing DSC capability somewhere in the chain, a dock that substitutes its own EDID, or outdated dock firmware. Check the EDID and DPCD before changing drivers.

Where Safeguard fits

Safeguard does not analyse display hardware, cables, EDID data, monitor firmware or dock firmware, and it does not manage devices. Its fit here is indirect. The software around display hardware is where it applies: the drivers and user space stacks you build into images, the open source libraries in kiosk and signage applications, the containers that run conference room or video wall software, and the build systems for products that ship display stacks. Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects contain a given component and version, and can open fix pull requests when a fixed version exists.

Display products ship a lot of open source: the kernel DRM drivers, libdrm, EDID parsers, CEC libraries and the web and media stacks inside signage players and TVs. The hardware stays the hardware, but the software images built around it pull those components again with every rebuild, and that is where supply chain hygiene still matters.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos show Safeguard on ordinary software projects, not on display hardware or firmware. They apply to the repositories and images around a display product or a fleet of signage machines.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same ask, approve and test loop suits a signage or kiosk application repository where every dependency change should be reviewed before it ships.

Click through it at your own pace, or open it full screen.

Image build hosts for embedded display products are often kept off the general network. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on such a build host can scan the source trees and container images stored there.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about known vulnerabilities in the projects that hold your display application and image build tooling, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• HDMI 2.2 Specification overview, HDMI Licensing Administrator
• HDMI Specifications and Programs, HDMI Licensing Administrator
• HDMI Licensing Administrator home page and press announcements
• HDMI press releases index
• HDMI 2.2 bandwidths and resolutions
• Ultra96 feature name, HDMI Licensing Administrator
• Ultra96 and Ultra High Speed HDMI Cables
• HDMI Specification 1.4b
• New Ultra High Speed HDMI Cable certification program, HDMI Forum press release, 6 January 2020
• About DisplayPort, VESA
• DisplayPort overview, displayport.org
• VESA publishes DisplayPort standard version 1.4
• VESA publishes DisplayPort 2.0
• VESA releases DisplayPort 2.1
• VESA brings DisplayPort to new USB Type-C connector
• VESA releases DisplayPort Alt Mode 2.0
• VESA Display Stream Compression
• VESA standards list
• HDCP, Digital Content Protection LLC
• HDCP specifications, Digital Content Protection LLC
• HDCP Specification Revision 1.4
• HDCP on HDMI Specification Revision 2.3
• Kernel Mode Setting (KMS), Linux kernel documentation
• Mode Setting Helper Functions, Linux kernel documentation
• EDID, Linux kernel admin guide
• CEC introduction, Linux kernel documentation
• drm_dp.h, Linux kernel source
• DRM display helper Kconfig, Linux kernel source
• edid-decode(1) manual page, Debian
• cec-ctl(1) manual page, Debian
• LVFS introduction, LVFS documentation
• CVE-2021-47444, NVD
• CVE-2022-49222, NVD
• CVE-2025-38254, NVD
• CVE-2026-64546, NVD
• CVE-2026-68255, NVD

Last reviewed: 25 October 2026. Display standards are revised regularly; check hdmi.org, vesa.org and digital-cp.com for the latest versions.