Unpacking EDID

A presenter walks into a conference room, plugins in their laptop, and gets a blank screen. Or the image shows up at the wrong resolution. Or there’s no audio. These are the kind of help desk tickets that can all trace back to a single root cause: EDID – Extended Display Identification Data.

EDID is the handshake between a source device (such as a laptop or cable box) and a display that tells the source what resolution, refresh rate, audio format, and color depth to send. Usually, nobody notices it, but when it breaks, it can become a support issue.

This guide covers what EDID is, how it evolved, and its data structure.

Why EDID Exists

EDID is a standardized metadata format that lets a display tell a source device what the display can do. It’s stored in a small chip inside every modern monitor, TV, and projector, and it gets automatically read whenever a source device connects. The source device (laptop, cable box, etc.) parses the EDID and then configures its video output to match the capabilities of the display.

Before EDID, there wasn’t a commonly accepted automatic way for a graphics card to know what it was connected to. Users had to manually select resolutions and refresh rates, and wrong choices could produce distorted images or even damage CRT monitors.

For a single desk monitor or display, manual configuration is an inconvenience. For enterprises managing meeting rooms, training rooms, boardrooms, auditoriums, hot desks – each with its own display, codec, and cable infrastructure – manual configuration becomes infeasible. EDID is what makes plug-and-play possible in these environments. When a presenter walks into a room and connects their laptop, EDID is the mechanism that negotiates the right video and audio settings for a smooth experience.

A Brief History of EDID

1994 – EDID v1.0 was introduced alongside the DDC (Display Data Channel) standard. It defined a 128-byte data structure for VGA monitors to communicate basic capabilities to a PC graphics card. VESA repurposed three pins on the VGA connector as a serial bus to carry this data.

1996-1997 – EDID v1.1 and v1.2 added monitor name descriptors and refined existing data fields. EDID v2.0 attempted a complete redesign with a 256-byte format, but it never gained adoption and was eventually abandoned.

2000 – E-EDID and EDID v1.3 corrected course. Enhanced EDID kept the proven 128-byte base block but added support for extension blocks — additional 128-byte chunks appended after Block 0. This was the version adopted by HDMI 1.0 through 1.3c, and it’s still common in installed AV equipment.

2006 – EDID v1.4 refined the base structure and is the current standard version. It improved digital input identification and relaxed some descriptor requirements.

2007 onward – DisplayID was released by VESA as a next-generation replacement. It uses variable-length structures and supports modern display types (tiled displays, HDR, VR headsets). DisplayID can be carried as an extension within the existing EDID framework, so the two coexist in practice.

The CEA-861 extension (now CTA-861, maintained by the Consumer Technology Association) deserves special mention. This is the extension block that carries HDMI-specific data -audio capabilities, consumer video timings, HDMI version features, HDR metadata, and Dolby Vision support. If you’re deploying HDMI-connected displays in meeting rooms, the CEA-861 block is where most of the action is.

How EDID Works

The base EDID is exactly 128 bytes. It’s compact, binary, and precisely structured. If you ever need to read an EDID dump from a diagnostic tool here’s what you’re looking at.

Bytes 0–7: Header

Eight fixed bytes: 00 FF FF FF FF FF FF 00. This is the signature that confirms the data is a valid EDID block. If your diagnostic tool shows a different pattern here, the EDID read failed or the data is corrupt.

Bytes 8–17: Vendor and Product Identification

Ten bytes identifying the manufacturer (a compressed three-letter PNP ID), product code, serial number, and manufacturing date. This is how your asset management or room monitoring system identifies what display is connected -“Samsung QM75R,” “LG 55UH5F,” or “Crestron DM‑MD8X8.” When a display reports the wrong identity, this is the section that’s off.

Bytes 18–19: EDID Version

Two bytes: version and revision. You’ll most commonly see 01 03 (v1.3, standard for HDMI up to 1.3c) or 01 04 (v1.4, current). Knowing the version helps when troubleshooting – v1.3 has stricter requirements about which descriptor blocks must be present.

Bytes 20–24: Basic Display Parameters

Five bytes that pack a lot of information. The first byte indicates digital versus analog input and, for digital, the bit depth and interface type. The next two bytes give the physical screen size in centimeters (used by the OS to calculate scaling/DPI — relevant when a meeting room PC needs to match the display’s native scaling). One byte encodes the gamma value. The final byte is a feature bitmap covering power management, color format support (RGB, YCbCr), and whether the first Detailed Timing Descriptor represents the display’s native resolution.

Bytes 25–34: Color Characteristics

Ten bytes of chromaticity data describing the display’s red, green, blue, and white point coordinates in the CIE 1931 color space. In a typical meeting room deployment, these values matter most when you’re standardizing color performance across rooms – for example, ensuring a training room’s projection matches the content creator’s intent.

Bytes 35–37: Established Timings

Three bytes forming a bitfield of legacy resolutions: 640×480, 800×600, 1024×768, and a few others. These are mostly irrelevant for modern 4K displays but remain in the structure for backward compatibility. A source may fall back to one of these if it can’t parse the rest of the EDID.

Bytes 38–53: Standard Timings

Sixteen bytes defining up to eight additional resolutions in a compact two-byte format (horizontal pixels and aspect ratio/refresh rate). The encoding requires horizontal resolution to be divisible by 8, which creates edge cases for some panel resolutions. Unused entries are filled with 01 01.

Bytes 54–125: Four 18-Byte Descriptor Blocks

This is the most important section for troubleshooting. Each 18-byte block is either a Detailed Timing Descriptor (DTD) or a Display Descriptor.

Detailed Timing Descriptors fully specify a video mode: pixel clock, active resolution, blanking intervals, sync timings, and image size. The first DTD is the display’s preferred timing: this is the resolution and refresh rate the display is asking the source to output. In a meeting room, if the display is showing 1080p when it’s a native 4K panel, the first DTD is the place to check.

Display Descriptors carry non-timing metadata. Key types include:

• Monitor Name (tag FC): The human-readable name your OS displays in settings: “SAMSUNG” or “LG TV.” When a room monitoring system shows “Unknown Display,” this descriptor is missing or malformed.
• Monitor Range Limits (tag FD): The safe frequency ranges for the display. If a source tries to output a timing outside these limits, a well-behaved graphics driver will refuse.
• Serial Number (tag FF): An ASCII serial string, separate from the binary serial in bytes 12–15.

Byte 126: Extension Count

Indicates how many additional 128-byte extension blocks follow. For HDMI displays in meeting rooms, this is almost always at least 01 (one CEA-861 extension). A value of 00 on an HDMI display is a red flag that means the display isn’t advertising any HDMI-specific capabilities, which will cause audio and advanced video features to fail.

Byte 127: Checksum

A single byte that makes the entire 128-byte block sum to zero (mod 256). A checksum failure means the data is corrupt, possibly from a bad cable, a flaky extender, or electrical interference on the DDC lines.

The CEA-861 Extension

The base EDID block was designed in the VGA era. Everything that makes HDMI useful in a modern meeting room: audio transport, consumer video formats, 4K, HDR, and wide color lives in the CEA-861 extension block.

This second 128-byte block contains a Data Block Collection made up of tagged sub-blocks:

• Video Data Blocks: Lists of supported video formats using one-byte Video Identification Codes (VICs). This is how a display advertises support for 1080p/60 (VIC 16), 4K/30 (VIC 95), 4K/60 (VIC 97), and other timings. If a room display supports 4K but the source only outputs 1080p, check whether the correct VICs are present.
• Audio Data Blocks: Three-byte Short Audio Descriptors specifying supported audio codecs (LPCM, AC-3, DTS, AAC, etc.), channel counts, and sample rates. This is critical for meeting rooms. If the EDID doesn’t advertise audio support, the source device won’t send audio over HDMI at all, and your room’s soundbar or DSP will be silent.
• Speaker Allocation Data Blocks: Describes the speaker configuration (stereo, 5.1, 7.1, etc.). In a meeting room, this is usually two-channel stereo, but training rooms or boardrooms with surround sound need accurate speaker data.
• Vendor Specific Data Blocks (VSDB): Carry HDMI version features. The HDMI Licensing VSDB (identified by IEEE code 00 0C 03) covers HDMI 1.4 capabilities like 3D and deep color. The HDMI Forum VSDB (C4 5D D8) covers HDMI 2.0 features including 4K at 60 Hz with 4:4:4 chroma. If you’re deploying HDMI 2.0 or 2.1 displays and the source isn’t outputting the expected bandwidth, a missing or truncated VSDB is a likely cause.
• HDR Static Metadata and Colorimetry Data Blocks: Advertise support for HDR10, HLG, BT.2020, and DCI-P3. These matter for executive briefing rooms or digital signage where color accuracy and HDR content are priorities.

When an AV switcher, extender, or wireless presentation system sits between the source and the display, it must faithfully relay this extension block to the source. Many EDID-related failures in enterprise AV trace back to intermediate devices that truncate, modify, or fail to pass through the CEA-861 extension.

Have questions about your meeting room setup? We love to help! Contact Us – UnifiedCommunications.com