EDID: The Display's Passport

Extended Display Identification Data: a small EEPROM in the display, read by the source over the DDC wires (plain I²C at address 0x50) the moment a cable connects. VESA defined it in 1994 for VGA monitors; the same 128-byte base block, now almost always with a CTA-861 extension behind it, still governs every HDMI and DisplayPort handshake today (DisplayPort's richer DisplayID is arriving, but EDID remains the lingua franca).

It is the display's half of the negotiation the Bandwidth Bucket module warned about: the source never sees the panel, only this passport, so whatever these bytes say, true or not, becomes the truth the source acts on.

The base block reads like a form: an 8-byte magic header; the maker's three-letter PNP code packed into two bytes; product, serial and date; one byte each for size and gamma; a feature byte; ten bytes of chromaticity; timing bitmaps; and four 18-byte descriptor slots (the first holding the preferred video timing, the others text: name, range limits). Byte 126 counts extension blocks; byte 127 makes the block sum to zero, the checksum that keeps corrupt passports from crashing sources.

The CTA-861 extension is where modern color lives: a header whose bits already declare Y′CbCr support, then a chain of tagged data blocks (video formats (SVDs), audio, the HDMI vendor block, colorimetry, HDR metadata, video capability), each color-coded in the dump above. Hover any byte to see which field owns it.

Bytes 0x19–0x22 are the purest color science in the file: the display's red, green, blue and white points as CIE 1931 xy coordinates, each a 10-bit fixed-point fraction (x · 1024 split across the bytes). Toggle the PRIMARIES chips and watch exactly ten bytes change: that is a gamut being declared. Byte 0x17 is gamma: (γ × 100) − 100, so 0x78 = 120 means 2.2.

This is where operating systems get their default color management: an ICC profile built 'from EDID' is built from these ten bytes. They are also the most commonly wrong bytes in the wild, copied from a reference design, never measured. A probe reads the panel; the EDID reads the datasheet. When they disagree, believe the probe (see Instruments).

Three separate declarations stack up. The base feature byte and the CTA header bits say which pixel formats arrive (RGB always; Y′CbCr 4:4:4 / 4:2:2 as flags; 4:2:0 via its own blocks). The Colorimetry Data Block says which encodings the display can interpret (xvYCC, BT.2020 YCC, BT.2020 RGB, a DCI-P3 flag), one bit each. And the base chromaticity bytes state what the panel physically covers. Three different questions: what format, what encoding, what gamut.

The source cross-references all three before choosing what to send, which is why a TV that omits one bit gets 8-bit Rec. 709 from a player that could have sent BT.2020 PQ. One absent bit silently downgrades the whole chain. When HDR 'mysteriously won't engage,' this block is the first suspect.

The HDR Static Metadata block is four bits and three codes. The bits list the EOTFs the display accepts (SDR gamma, traditional HDR gamma, PQ (ST 2084), HLG). This is literally how a TV tells a player 'I speak PQ.' The codes state luminance logarithmically: max luminance = 50 · 2^(code/32) cd/m², so code 96 ≈ 400 nits, code 138 ≈ 1,000. Toggle MAX NITS and watch one byte move.

Sources tone-map from these numbers: a player seeing 'max 600' may compress a 4,000-nit master before the TV applies its own opinion, two tone maps in a row is how HDR gets double-graded on its way to the screen. Calibrating HDR starts with knowing exactly what this block claims (see Transfer Functions and Dynamic Range).

One bit in the Video Capability Data Block, QS, tells the source whether this display accepts an explicit full-range/limited-range instruction. With it set, the source declares the range it sends in the AVI InfoFrame; without it, both ends fall back to convention (limited for video timings, full for PC timings) and hope they guessed alike.

The entire washed-out-blacks / crushed-shadows pathology of the Signal Range module hangs off this single bit. If you have ever toggled 'HDMI black level' or 'RGB range: Auto/Full/Limited,' you were manually doing what QS automates.

In a real installation the source rarely reads the display's own EDID. AVRs, matrices, extenders and splitters each present their own, often a lowest-common-denominator composite of everything downstream, or a stale copy from whatever was connected at boot. Panels ship with copied chromaticities, absent QS bits, and HDR blocks written by marketing. The chain believes whichever passport it happens to read.

That is why EDID tooling is a working discipline: Analog Way's free AW EDID Editor reads, edits and writes exactly the .bin files this page exports; hardware EDID emulators and managers pin a known-good passport in front of a source so the chain stops guessing; every serious matrix has an EDID management page for the same reason. Build the EDID you wish the chain presented, then make the chain present it.

Start every job by reading the passport: switch this page to READ / DECODE and drop in a captured EDID. Three questions before the probe comes out: does the EDID the source reads match the display's own, or did an AVR substitute its composite? Do the colorimetry and HDR blocks declare what the client believes they bought? Is QS set, or is the chain guessing ranges?

Half of 'the display looks wrong' calls are really 'the source was told wrong.' Fix the declaration, re-handshake, and only then measure what the panel does with what it now correctly receives.