Hubbry Logo
search
logo
Extended Display Identification Data avatar
Extended Display Identification Data
Extended Display Identification Data
current hub
E

Extended Display Identification Data

logo
Community Hub0 Subscribers
Read side by side
Extended Display Identification Data
View on Wikipedia
from Wikipedia

Extended Display Identification Data (EDID) and Enhanced EDID (E-EDID) are metadata formats for display devices to describe their capabilities to a video source (e.g., graphics card or set-top box). The data format is defined by a standard published by the Video Electronics Standards Association (VESA).

The EDID data structure includes manufacturer name and serial number, product type, phosphor or filter type (as chromaticity data), timings supported by the display, display size, luminance data and (for digital displays only) pixel mapping data.

DisplayID is a VESA standard targeted to replace EDID and E-EDID extensions with a uniform format suited for both PC monitor and consumer electronics devices.

Background

[edit]

EDID structure (base block) versions range from v1.0 to v1.4; all these define upwards-compatible 128-byte structures. Version 2.0 defined a new 256-byte structure but it has been deprecated and replaced by E-EDID which supports multiple extension blocks.[citation needed] HDMI versions 1.0–1.3c use E-EDID v1.3.[1]

Before Display Data Channel (DDC) and EDID were defined, there was no standard way for a graphics card to know what kind of display device it was connected to. Some VGA connectors in personal computers provided a basic form of identification by connecting one, two or three pins to ground, but this coding was not standardized.

This problem is solved by EDID and DDC, as it enables the display to send information to the graphics card it is connected to. The transmission of EDID information usually uses the Display Data Channel protocol, specifically DDC2B, which is based on I²C-bus (DDC1 used a different serial format which never gained popularity). The data is transmitted via the cable connecting the display and the graphics card; VGA, DVI, DisplayPort and HDMI are supported.[citation needed]

The EDID is often stored in the monitor in the firmware chip called serial EEPROM (electrically erasable programmable read-only memory) and is accessible via the I²C-bus at address 0x50. The EDID PROM can often be read by the host PC even if the display itself is turned off.

Many software packages can read and display the EDID information, such as read-edid[2] for Linux and DOS, PowerStrip[3] for Microsoft Windows and the X.Org Server for Linux and BSD unix. Mac OS X natively reads EDID information and programs such as SwitchResX[4] or DisplayConfigX[5] can display the information as well as use it to define custom resolutions.

E-EDID was introduced at the same time as E-DDC, which supports multiple extensions blocks and deprecated EDID version 2.0 structure (it can be incorporated in E-EDID as an optional extension block). Data fields for preferred timing, range limits, and monitor name are required in E-EDID. E-EDID also adds support for the Dual GTF curve concept and partially changed the encoding of aspect ratio within the standard timings.

With the use of extensions, E-EDID structure can be extended up to 32 KiB, because the E-DDC added the capability to address multiple (up to 128) 256 byte segments.

EDID Extensions assigned by VESA

[edit]
  • Timing Extension (00)
  • Additional Timing Data Block (CTA EDID Timing Extension) (02)
  • Video Timing Block Extension (VTB-EXT) (10)
  • EDID 2.0 Extension (20)
  • Display Information Extension (DI-EXT) (40)
  • Localized String Extension (LS-EXT) (50)
  • Microdisplay Interface Extension (MI-EXT) (60)
  • Display ID Extension (70)
  • Display Transfer Characteristics Data Block (DTCDB) (A7, AF, BF)
  • Block Map (F0)
  • Display Device Data Block (DDDB) (FF): contains information such as subpixel layout[6]
  • Extension defined by monitor manufacturer (FF): According to LS-EXT, actual contents varies from manufacturer. However, the value is later used by DDDB.

Revision history

[edit]
  • August 1994, DDC standard version 1 – introduce EDID v1.0.
  • April 1996, EDID standard version 2 – introduce EDID v1.1.
  • November 1997, EDID standard version 3 – introduce EDID v1.2 and EDID v2.0.
  • September 1999, E-EDID Standard Release A – introduce EDID v1.3 and E-EDID v1.0, which supports multiple extensions blocks.
  • February 2000, E-EDID Standard Release A - introduce E-EDID v1.3 (used in HDMI), based on EDID v1.3. EDID v2.0 deprecated.
  • September 2006, E-EDID Standard Release A – introduce E-EDID v1.4, based on EDID v1.4.

Limitations

[edit]

Some graphics card drivers have historically coped poorly with the EDID, using only its standard timing descriptors rather than its Detailed Timing Descriptors (DTDs). Even in cases where the DTDs were read, the drivers are/were still often limited by the standard timing descriptor limitation that the horizontal/vertical resolutions must be evenly divisible by 8. This means that many graphics cards cannot express the native resolutions of the most common widescreen flat-panel displays and liquid-crystal display TVs. The number of vertical pixels is calculated from the horizontal resolution and the selected aspect ratio. To be fully expressible, the size of widescreen display must thus be a multiple of 16×9 pixels. For 1366×768 pixel Wide XGA panels the nearest resolution expressible in the EDID standard timing descriptor syntax is 1360×765 pixels, typically leading to 3-pixel-thin black bars. Specifying 1368 pixels as the screen width would yield an unnatural screen height of 769.5 pixels.

Many Wide XGA panels do not advertise their native resolution in the standard timing descriptors, instead offering only a resolution of 1280×768. Some panels advertise a resolution only slightly smaller than the native, such as 1360×765. For these panels to be able to show a pixel perfect image, the EDID data must be ignored by the display driver or the driver must correctly interpret the DTD and be able to resolve resolutions whose size is not divisible by 8. Special programs are available to override the standard timing descriptors from EDID data. Even this is not always possible, as some vendors' graphics drivers (notably those of Intel) require specific registry hacks to implement custom resolutions, which can make it very difficult to use the screen's native resolution.[7]

EDID 1.4 data format

[edit]

Structure, version 1.4

[edit]
EDID structure, version 1.4[8][9]
Bytes Description
0–19 Header information
0–7 Fixed header pattern: 00 FF FF FF FF FF FF 00
8–9 Manufacturer ID. This is a legacy Plug and Play ID assigned by UEFI forum, which is a big-endian 16-bit value made up of three 5-bit letters: 00001, A; 00010, B; ...; 11010, Z. E.g.: 24 4d, 0 01001 00010 01101, "IBM"; "PHL" (Philips).
Bit 15 0 = reserved
Bits 14–10 First letter of manufacturer ID (byte 8, bits 6–2)
Bits 9–5 Second letter of manufacturer ID (byte 8, bit 1 through byte 9 bit 5)
Bits 4–0 Third letter of manufacturer ID (byte 9 bits 4–0)
10–11 Manufacturer product code. 16-bit hex number, little-endian. For Example, "PHL" + "C0CF".
12–15 Serial number. 32 bits, little-endian.
16 Week of manufacture; or FF model year flag. Week numbering is not consistent between manufacturers.
17 Year of manufacture, or year of model, if model year flag is set. Year = datavalue + 1990.
18 EDID version, usually 01 (for 1.3 and 1.4)
19 EDID revision, usually 03 (for 1.3) or 04 (for 1.4)
20–24 Basic display parameters
20 Video input parameters bitmap
Bit 7 = 1 Digital input. If set, the following bit definitions apply:
Bits 6–4 Bit depth:

000 = undefined
001 = 6
010 = 8
011 = 10
100 = 12
101 = 14
110 = 16 bits per color
111 = reserved

Bits 3–0 Video interface:

0000 = undefined
0001 = DVI
0010 = HDMIa
0011 = HDMIb
0100 = MDDI
0101 = DisplayPort

Bit 7 = 0 Analog input. If clear, the following bit definitions apply:
Bits 6–5 Video white and sync levels, relative to blank:

00 = +0.7/−0.3 V
01 = +0.714/−0.286 V
10 = +1.0/−0.4 V
11 = +0.7/0 V (EVC)

Bit 4 Blank-to-black setup (pedestal) expected
Bit 3 Separate sync supported
Bit 2 Composite sync (on HSync) supported
Bit 1 Sync on green supported
Bit 0 VSync pulse must be serrated when composite or sync-on-green is used.
21 Horizontal screen size, in centimetres (range 1–255). If vertical screen size is 0, landscape aspect ratio (range 1.00–3.54), datavalue = (AR×100) − 99 (example: 16:9, 79; 4:3, 34.)
22 Vertical screen size, in centimetres. If horizontal screen size is 0, portrait aspect ratio (range 0.28–0.99), datavalue = (100/AR) − 99 (example: 9:16, 79; 3:4, 34.) If both bytes are 0, screen size and aspect ratio are undefined (e.g. projector)
23 Display gamma, factory default (range 1.00–3.54), datavalue = (gamma×100) − 100 = (gamma − 1)×100. If 255, gamma is defined by DI-EXT block.
24 Supported features bitmap
Bit 7 DPMS standby supported
Bit 6 DPMS suspend supported
Bit 5 DPMS active-off supported
Bits 4–3 Display type (digital):

00 = RGB 4:4:4
01 = RGB 4:4:4 + YCrCb 4:4:4
10 = RGB 4:4:4 + YCrCb 4:2:2
11 = RGB 4:4:4 + YCrCb 4:4:4 + YCrCb 4:2:2

Display type (analog):

00 = monochrome or grayscale
01 = RGB color
10 = non-RGB color
11 = undefined

Bit 2 Standard sRGB colour space. Bytes 25–34 must contain sRGB standard values.
Bit 1 Preferred timing mode specified in descriptor block 1. For EDID 1.3+ the preferred timing mode is always in the first Detailed Timing Descriptor. In that case, this bit specifies whether the preferred timing mode includes native pixel format and refresh rate.
Bit 0 Continuous timings with GTF or CVT
25–34 Chromaticity coordinates.
10-bit 2° CIE 1931 xy coordinates for red, green, blue, and white point
25 Red and green least-significant bits (2−9, 2−10)
Bits 7–6 Red x value least-significant 2 bits
Bits 5–4 Red y value least-significant 2 bits
Bits 3–2 Green x value least-significant 2 bits
Bits 1–0 Green y value least-significant 2 bits
26 Blue and white least-significant 2 bits
27 Red x value most significant 8 bits (2−1, ..., 2−8). 0–255 encodes fractional 0–0.996 (255/256); 0–0.999 (1023/1024) with lsbits
28 Red y value most significant 8 bits
29–30 Green x and y value most significant 8 bits
31–32 Blue x and y value most significant 8 bits
33–34 Default white point x and y value most significant 8 bits
35–37 Established timing bitmap. Supported bitmap for (formerly) very common timing modes.
35 Bit 7 720×400 @ 70 Hz (VGA)
Bit 6 720×400 @ 88 Hz (XGA)
Bit 5 640×480 @ 60 Hz (VGA)
Bit 4 640×480 @ 67 Hz (Apple Macintosh II)
Bit 3 640×480 @ 72 Hz
Bit 2 640×480 @ 75 Hz
Bit 1 800×600 @ 56 Hz
Bit 0 800×600 @ 60 Hz
36 Bit 7 800×600 @ 72 Hz
Bit 6 800×600 @ 75 Hz
Bit 5 832×624 @ 75 Hz (Apple Macintosh II)
Bit 4 1024×768 @ 87 Hz, interlaced (1024×768i)
Bit 3 1024×768 @ 60 Hz
Bit 2 1024×768 @ 70 Hz
Bit 1 1024×768 @ 75 Hz
Bit 0 1280×1024 @ 75 Hz
37 Bit 7 1152x870 @ 75 Hz (Apple Macintosh II)
Bits 6–0 Other manufacturer-specific display modes
38–53 Standard timing information. Up to 8 2-byte fields describing standard display modes.
Unused fields are filled with 01 01 hex. The following definitions apply in each record:
38 Standard timing 1: X resolution, 00 = reserved; otherwise, (datavalue + 31) × 8 (256–2288 pixels).
39 Bits 7–6 Standard timing 1: Image aspect ratio:

00 = 16:10
01 = 4:3
10 = 5:4
11 = 16:9
(Versions prior to 1.3 defined 00 as 1:1.)

Bits 5–0 Vertical frequency, datavalue + 60 (60–123 Hz)
40-41 Standard timing 2
42-43 Standard timing 3
44-45 Standard timing 4
46-47 Standard timing 5
48-49 Standard timing 6
50-51 Standard timing 7
52-53 Standard timing 8
54–125 Display timing descriptor followed by display/monitor descriptors
54–71 Preferred timing descriptor 18 byte detailed timing descriptors or display descriptors
72–89 Descriptor 2
90–107 Descriptor 3
108–125 Descriptor 4
126-127 Extension flag and checksum
126 Number of extensions to follow. 0 if no extensions.
127 Checksum. Sum of all 128 bytes should equal 0 (mod 256).

Detailed Timing Descriptor

[edit]
EDID Detailed Timing Descriptor[8]
Bytes Description
0–1 Pixel clock. 00 = reserved; otherwise in 10 kHz units (0.01–655.35 MHz, little-endian).
2 Horizontal active pixels 8 lsbits (0–255)
3 Horizontal blanking pixels 8 lsbits (0–255) End of active to start of next active.
4 Bits 7–4 Horizontal active pixels 4 msbits (0–15)
Bits 3–0 Horizontal blanking pixels 4 msbits (0–15)
5 Vertical active lines 8 lsbits (0–255)
6 Vertical blanking lines 8 lsbits (0–255)
7 Bits 7–4 Vertical active lines 4 msbits (0–15)
Bits 3–0 Vertical blanking lines 4 msbits (0–15)
8 Horizontal front porch (sync offset) pixels 8 lsbits (0–255) From blanking start
9 Horizontal sync pulse width pixels 8 lsbits (0–255)
10 Bits 7–4 Vertical front porch (sync offset) lines 4 lsbits (0–15)
Bits 3–0 Vertical sync pulse width lines 4 lsbits (0–15)
11 Bits 7–6 Horizontal front porch (sync offset) pixels 2 msbits (0–3)
Bits 5–4 Horizontal sync pulse width pixels 2 msbits (0–3)
Bits 3–2 Vertical front porch (sync offset) lines 2 msbits (0–3)
Bits 1–0 Vertical sync pulse width lines 2 msbits (0–3)
12 Horizontal image size, mm, 8 lsbits (0–255 mm, 161 in)
13 Vertical image size, mm, 8 lsbits (0–255 mm, 161 in)
14 Bits 7–4 Horizontal image size, mm, 4 msbits (0–15)
Bits 3–0 Vertical image size, mm, 4 msbits (0–15)
15 Horizontal border pixels (one side; total is twice this) (0–255)
16 Vertical border lines (one side; total is twice this) (0–255)
17 Features bitmap
Bit 7 Signal Interface Type:

0 = non-interlaced;
1 = interlaced.

Bits 6–5 Stereo mode (combine bits 6–5 with bit 0):

00 x = none, bit 0 is "don't care";
01 0 = field sequential, right during stereo sync;
10 0 = field sequential, left during stereo sync;
01 1 = 2-way interleaved, right image on even lines;
10 1 = 2-way interleaved, left image on even lines;
11 0 = 4-way interleaved;
11 1 = side-by-side interleaved.

Bit 4 = 0 Analog sync.
If set, the following bit definitions apply:
Bit 3 Sync type:

0 = analog composite;
1 = bipolar analog composite.

Bit 2 Serration:

0 = without serrations;
1 = with serrations (H-sync during V-sync).

Bit 1 Sync on red and blue lines additionally to green

0 = sync on green signal only;
1 = sync on all three (RGB) video signals.

Bits 4–3 = 10 Digital sync., composite (on HSync).
If set, the following bit definitions apply:
Bit 2 Serration

0 = without serration;
1 = with serration (H-sync during V-sync).

Bit 1 Horizontal sync polarity:

0 = negative;
1 = positive.

Bits 4–3 = 11 Digital sync., separate
If set, the following bit definitions apply:
Bit 2 Vertical sync polarity:

0 = negative;
1 = positive.

Bit 1 Horizontal sync polarity:

0 = negative;
1 = positive.

Bit 0 Stereo mode (combines with bits 6–5)

When used for another descriptor, the pixel clock and some other bytes are set to 0:

Monitor Descriptors

[edit]
EDID Monitor Descriptors[8]
Bytes Description
0–1 0 = Monitor Descriptor (cf. Detailed Timing Descriptor).
2 0 = reserved
3 Descriptor type. FA–FF currently defined. 00–0F reserved for vendors.
4 0 = reserved, except for Display Range Limits Descriptor.
5–17 Defined by descriptor type. If text, code page 437 text, terminated (if less than 13 bytes) with LF and padded with SP.

Currently defined descriptor types are:

  • FF: Monitor serial number (ASCII text)
  • FE: Unspecified text (ASCII text)
  • FD: Monitor range limits. 6- or 13-byte (with additional timing) binary descriptor.
  • FC: Monitor name (ASCII text), for example "PHL 223V5".
  • FB: Additional white point data. 2× 5-byte descriptors, padded with 0A 20 20.
  • FA: Additional standard timing identifiers. 6× 2-byte descriptors, padded with 0A.
  • F9: Display Color Management (DCM).
  • F8: CVT 3-Byte Timing Codes.
  • F7: Additional standard timing 3.
  • 10: Dummy identifier.
  • 00–0F: Manufacturer reserved descriptors.

Display Range Limits

[edit]

Descriptor

[edit]
EDID Display Range Limits Descriptor[8]
Bytes Description
0–1 00 00 = Display Descriptor
2 00 = reserved
3 FD = Display Range Limits Descriptor
4 Offsets for display range limits
Bits 7–4 00 = reserved
Bits 3–2 Horizontal rate offsets:

00 = none;
10 = +255 kHz for max. rate;
11 = +255 kHz for max. and min. rates.

Bits 1–0 Vertical rate offsets:

00 = none;
10 = +255 Hz for max. rate;
11 = +255 Hz for max. and min. rates.

5 Minimum vertical field rate (1–255 Hz; 256–510 Hz, if offset).
6 Maximum
7 Minimum horizontal line rate (1–255 kHz; 256–510 kHz, if offset).
8 Maximum
9 Maximum pixel clock rate, rounded up to 10 MHz multiple (10–2550 MHz).
10 Extended timing information type:

00 = Default GTF (when basic display parameters byte 24, bit 0 is set).
01 = No timing information.
02 = Secondary GTF supported, parameters as follows.
04 = CVT (when basic display parameters byte 24, bit 0 is set), parameters as follows.

11–17 Video timing parameters (if byte 10 is 00 or 01, padded with 0A 20 20 20 20 20 20).

With GTF secondary curve

[edit]
EDID Display Range Limits with GTF Secondary curve[8]
Bytes Description
10 02
11 00 = reserved
12 Start frequency for secondary curve, divided by 2 kHz (0–510 kHz)
13 GTF C value, multiplied by 2 (0–127.5)
14–15 GTF M value (0–65535, little-endian)
16 GTF K value (0–255)
17 GTF J value, multiplied by 2 (0–127.5)

With CVT support

[edit]
EDID Display Range Limits with CVT support[8]
Bytes Description
10 04
11 Bits 7–4 CVT major version (1–15)
Bits 3–0 CVT minor version (0–15)
12 Bits 7–2 Additional clock precision in 0.25 MHz increments
(to be subtracted from byte 9 maximum pixel clock rate)
Bits 1–0 Maximum active pixels per line, 2-bit msb
13 Maximum active pixels per line, 8-bit lsb (no limit if 0)
14 Aspect ratio bitmap
Bit 7 4∶3
Bit 6 16∶9
Bit 5 16∶10
Bit 4 5∶4
Bit 3 15∶9
Bits 2–0 000 = reserved
15 Bits 7–5 Aspect ratio preference:

000 = 4∶3
001 = 16∶9
010 = 16∶10
011 = 5∶4
100 = 15∶9

Bit 4 CVT-RB reduced blanking (preferred)
Bit 3 CVT standard blanking
Bits 2–0 000 = reserved
16 Scaling support bitmap
Bit 7 Horizontal shrink
Bit 6 Horizontal stretch
Bit 5 Vertical shrink
Bit 4 Vertical stretch
Bits 3–0 0000 = reserved
17 Preferred vertical refresh rate (1–255)

Additional white point descriptor

[edit]
EDID additional white point descriptor[8]
Bytes Description
0–4 00 00 00 FB 00
5 White point index number (1–255). Usually 1; 0 indicates descriptor not used.
6 White point CIE xy coordinates least-significant bits (like EDID byte 26)
Bits 7–4 000 = reserved
Bits 3–2 White point x value least-significant 2 bits
Bits 1–0 White point y value least-significant 2 bits
7 White point x value most significant 8 bits (like EDID byte 27)
8 White point y value most significant 8 bits (like EDID byte 28)
9 datavalue = (gamma − 1)×100 (1.0–3.54, like EDID byte 23)
10–14 Second descriptor. Index number starts with 2; if 0 = unused
15–17 Unused, padded with 0A 20 20.

Color management data descriptor

[edit]
EDID color management data descriptor[8]
Bytes Description
0–4 00 00 00 F9 00
5 Version: 03
6 Red a3 lsb
7 Red a3 msb
8 Red a2 lsb
9 Red a2 msb
10 Green a3 lsb
11 Green a3 msb
12 Green a2 lsb
13 Green a2 msb
14 Blue a3 lsb
15 Blue a3 msb
16 Blue a2 lsb
17 Blue a2 msb

CVT 3-byte timing codes descriptor

[edit]
EDID CVT 3-byte timing codes descriptor[8]
Bytes Description
0–4 00 00 00 F8 00
5 Version: 01
6-8 CVT timing descriptor #1
6 Addressable lines per field 8-bit lsb
7 Bits 7–4 Addressable lines per field 4-bit msb
Bits 3–2 Aspect ratio:

00 = 4∶3
01 = 16∶9
10 = 16∶10
11 = 15∶9

Bits 1–0 00 = reserved
8 Bit 7 0 = reserved
Bits 6–5 Preferred vertical rate:

00: 50 Hz
01: 60 Hz
10: 75 Hz
11: 85 Hz

Vertical rate bitmap
Bit 4 50 Hz CVT
Bit 3 60 Hz CVT
Bit 2 75 Hz CVT
Bit 1 85 Hz CVT
Bit 0 60 Hz CVT reduced blanking
9–11 CVT timing descriptor #2
12–14 CVT timing descriptor #3
15–17 CVT timing descriptor #4


Additional standard timings

[edit]
EDID Additional standard timings 3[8]
Bytes Description
0–4 00 00 00 F7 00
5 Version: 10
6 Bit 7 640×350 @ 85 Hz
Bit 6 640×400
Bit 5 720×400
Bit 4 640×480
Bit 3 848×480 @ 60 Hz
Bit 2 800×600 @ 85 Hz
Bit 1 1024×768
Bit 0 1152×864
7 Bit 7 1280×768 @ 60 Hz (CVT-RB)
Bit 6 @ 60 Hz
Bit 5 @ 75 Hz
Bit 4 @ 85 Hz
Bit 3 1280×960 @ 60 Hz
Bit 2 @ 85 Hz
Bit 1 1280×1024 @ 60 Hz
Bit 0 @ 85 Hz
8 Bit 7 1360×768 @ 60 Hz (CVT-RB)
Bit 6 1280×768 @ 60 Hz
Bit 5 1440×900 @ 60 Hz (CVT-RB)
Bit 4 @ 75 Hz
Bit 3 @ 85 Hz
Bit 2 1400×1050 @ 60 Hz (CVT-RB)
Bit 1 @ 60 Hz
Bit 0 @ 75 Hz
9 Bit 7 @ 85 Hz
Bit 6 1680×1050 @ 60 Hz (CVT-RB)
Bit 5 @ 60 Hz
Bit 4 @ 75 Hz
Bit 3 @ 85 Hz
Bit 2 1600×1200 @ 60 Hz
Bit 1 @ 65 Hz
Bit 0 @ 70 Hz
10 Bit 7 @ 75 Hz
Bit 6 @ 85 Hz
Bit 5 1792×1344 @ 60 Hz
Bit 4 @ 75 Hz
Bit 3 1856×1392 @ 60 Hz
Bit 2 @ 75 Hz
Bit 1 1920×1200 @ 60 Hz (CVT-RB)
Bit 0 @ 60 Hz
11 Bit 7 @ 75 Hz
Bit 6 @ 85 Hz
Bit 5 1920×1440 @ 60 Hz
Bit 4 @ 75 Hz
Bits 3–0 0000 = reserved
12–17 Unused, must be 0.

CTA EDID Timing Extension Block

[edit]

The CTA EDID Extension was first introduced in EIA/CEA-861.

CTA-861 Standard

[edit]

The ANSI/CTA-861 industry standard, which according to CTA is now their "Most Popular Standard",[10] has since been updated several times, most notably with the 861-B revision (published in May 2002, which added version 3 of the extension, adding Short Video Descriptors and advanced audio capability/configuration information), 861-D (published in July 2006 and containing updates to the audio segments), 861-E in March 2008,[11] 861-F, which was published on June 4, 2013,[12] 861-H in December 2020,[13] and, most recently, 861-I, which was published in February 2023.[14] Coinciding with the publication of CEA-861-F in 2013, Brian Markwalter, senior vice president, research and standards, stated: "The new edition includes a number of noteworthy enhancements, including support for several new Ultra HD and widescreen video formats and additional colorimetry schemes.”[15]

Version CTA-861-G,[16] originally published in November 2016, was made available for free in November 2017, along with updated versions -E and -F, after some necessary changes due to a trademark complaint. All CTA standards are free to everyone since May 2018.[17][18]

The most recent full version is CTA-861-I,[19] published in February 2023, available for free after registration. It combines the previous version, CTA-861-H,[20] from January 2021 with an amendment, CTA-861.6,[21] published in February 2022 and includes a new formula to calculate Video Timing Formats, OVT.[22] Other changes include a new annex to elaborate on the audio speaker room configuration system that was introduced with the 861.2 amendment, and some general clarifications and formatting cleanup.

An amendment to CTA-861-I, CTA-861.7,[23] was published in June 2024. It contains updates to CTA 3D Audio, and clarifications on Content Type Indication, and on 4:2:0 support for VTDBs and VFDBs. It also introduces a new Product ID Data Block, to replace the Manufacturer PNP ID in the first block of the EDID, since the UEFI is phasing out assigning new PNP IDs.

CTA Extension Block

[edit]

Version 1 of the extension block (as defined in CEA−861) allowed the specification of video timings only through the use of 18-byte Detailed Timing Descriptors (DTD) (as detailed in EDID 1.3 data format above). DTD timings are listed in order of preference in the CEA EDID Timing Extension.

Version 2 (as defined in 861-A) added the capability to designate a number of DTDs as "native" (i.e., matching the resolution of the display) and also included some "basic discovery" functionality for whether the display device contains support for "basic audio", YCBCR pixel formats, and underscan.

Version 3 (from the 861-B spec onward) allows two different ways to specify digital video timing formats: As in Version 1 & 2 by the use of 18-byte DTDs, or by the use of the Short Video Descriptor (SVD) (see below). HDMI 1.0–1.3c uses this[which?] version.

Version 3 also defines a format for a collection of data blocks, which in turn can contain a number of individual descriptors. This Data Block Collection (DBC) initially had four types of Data Blocks (DBs): Video Data Blocks containing the aforementioned Short Video Descriptor (SVD), Audio Data Blocks containing Short Audio Descriptors (SAD), Speaker Allocation Data Blocks containing information about the speaker configuration of the display device, and Vendor Specific Data Blocks which can contain information specific to a given vendor's use. Subsequent versions of CTA-861 defined additional data blocks.

CTA Extension data format

[edit]
Byte Description
0 Extension tag (which kind of extension block this is); 02 for CTA EDID
1 Revision number (version number); 03 for version 3
2 Byte number (decimal) within this block where the 18-byte DTDs begin. If no non-DTD data is present in this extension block, the value should be set to 04 (the byte after next). If set to 00, there are no DTDs present in this block and no non-DTD data.
3 With version 2 and up: number of Native DTDs present, other information. Reserved with earlier versions.
Bit 7 1 if display supports underscan, 0 if not
Bit 6 1 if display supports basic audio, 0 if not
Bit 5 1 if display supports YCBCR 4∶4∶4, 0 if not
Bit 4 1 if display supports YCBCR 4∶2∶2, 0 if not
Bit 3–0 Total number of native formats in the DTDs included in this block
4–126 With version 3 and up: Data Block Collection, starting at byte 4, ending immediately before the byte specified in byte 2. If byte 2 is 04, the collection is of zero length (i.e. not present). If byte 2 is 00, no DTDs are present and the DBC takes up the entire remaining EDID block ahead of the checksum. Reserved with earlier versions.
18-byte descriptors, starting at the byte specified in byte 2 (if non-zero). Consecutive descriptors are present while the bytes 0–1 of each are not 00 00.
Padding, from the absence of an 18-byte descriptor onwards; must be 00.
127 Checksum. Value such that the one-byte sum of all 128 bytes is 00.

The Data Block Collection contains one or more data blocks detailing video, audio, and speaker placement information about the display. The blocks can be placed in any order, and the initial byte of each block defines both its type and its length:

Data block header
Byte Description
0 Bit 7–5 Block Type Tag
  • 001 1: Audio (ADB, containing SADs)
  • 010 2: Video (VDB, containing SVDs)
  • 011 3: Vendor Specific (VSDB)
  • 100 4: Speaker Allocation (SADB)
  • 101 5: VESA Display Transfer Characteristic (VESA DTCDB)
  • 110 6: Video Format (VFDB, containing VFDs)
  • 111 7: Use Extended Tag
Bit 4–0 Total number of bytes in this block following this byte.

If the Tag code is 7, an Extended Tag Code is present in the first payload byte of the data block, and the second payload byte represents the first payload byte of the extended data block.

Extended Block Type Tag
Byte Description
1 Bit 7–0 Extended Block Type Tag
  • 00000000 0: Video Capability (VCDB)
  • 00000001 1: Vendor Specific Video (VSVDB)
  • 00000010 2: VESA Display Device (VESA DDDB)
  • 00000011 3: reserved for VESA
  • 00000100 4: reserved for HDMI
  • 00000101 5: Colorimetry (CDB)
  • 00000110 6: HDR Static Metadata (HDR SMDB)
  • 00000111 7: HDR Dynamic Metadata (HDR DMDB)
  • 00001000 8: Native Video Resolution (NVRDB)
  • 9-12: reserved for video
  • 00001101 13: Video Format Preference (VFPDB)
  • 00001110 14: YCBCR 4:2:0 Video (Y420VDB)
  • 00001111 15: YCBCR 4:2:0 Capability Map (Y420CMDB)
  • 00010000 16: reserved for CTA (CTA MAF)
  • 00010001 17: Vendor Specific Audio (VSADB)
  • 00010010 18: HDMI Audio (HDMI ADB)
  • 00010011 19: Room Configuration (RCDB)
  • 00010100 20: Speaker Location (SLDB, containing SLDs)
  • 21-31: reserved for audio
  • 00100000 32: InfoFrame (IFDB)
  • 00100001 33: reserved
  • 00100010 34: Type VII video timing (T7VTDB)
  • 00100011 35: Type VIII video timing (T8VTDB)
  • 36-41: reserved
  • 00101010 42: Type X video timing (T10VTDB)
  • 42-119: reserved
  • 01111000 120: HDMI Forum EDID Extension Override (HF-EEODB)
  • 01111001 121: HDMI Forum Sink Capbility (HF-SCDB)
  • 01111010 122: HDMI Forum Source-Based Tone Mapping (HF-SBTMDB)
  • 123-127: reserved for HDMI
  • else: reserved

Once one data block has ended, the next byte is assumed to be the beginning of the next data block. This is the case until the byte (designated in byte 2, above) where the DTDs are known to begin.

CTA Data Blocks

[edit]

As noted, several data blocks are defined by the extension.

Video Data Blocks

[edit]

The Video Data Blocks will contain one or more 1-byte Short Video Descriptors (SVDs).

Byte Description
0 Data block header
1 Bit 7 1 to designate that this should be considered a "native" resolution, 0 for non-native. Used for 7-bit VICs 1 – 64 only, otherwise this is the MSB for the 8-bit VIC.
Bit 6–0 VIC: Index value to a table of standard resolutions/timings from EIA/CEA-861:
EIA/CEA-861 predefined standard resolutions and timings
[edit]
EIA/CEA-861 standard resolutions and timings
VIC Short name Aspect ratio Clock Active Total Field rate (Hz)
DAR PAR Pixel (MHz) V (Hz) H (kHz) H V H V
1 DMT0659 4∶3 1∶1 25.175 59.94 31.469 640 480 800 525 60
2 480p 4∶3 8∶9 27 59.94 31.469 720 480 858 525 60
3 480pH 16∶9 32∶27 27 59.94 31.469 720 480 858 525 60
4 720p 16∶9 1∶1 74.25 60 45.0 1280 720 1650 750 60
5 1080i 16∶9 1∶1 74.25 60 33.75 1920 540 2200 562.5 60
6 480i 4∶3 8∶9 27 59.94 15.734 1440 240 1716 262.5 60
7 480iH 16∶9 32∶27 27 59.94 15.734 1440 240 1716 262.5 60
8 240p 4∶3 4∶9 27 59.826 15.734 1440 240 1716 262.5 60
9 240pH 16∶9 16∶27 27 59.826 15.734 1440 240 1716 262.5 60
10 480i4x 4∶3 2:9-20:9 54 59.94 15.734 2880 240 3432 262.5 60
11 480i4xH 16∶9 8:27-80:27 54 59.94 15.734 2880 240 3432 262.5 60
12 240p4x 4∶3 1:9-10:9 54 60 15.734 2880 240 3432 262.5 60
13 240p4xH 16∶9 4:27-40:27 54 60 15.734 2880 240 3432 262.5 60
14 480p2x 4∶3 4:9, 8∶9 54 59.94 31.469 1440 480 1716 525 60
15 480p2xH 16∶9 16:27, 32∶27 54 59.94 31.469 1440 480 1716 525 60
16 1080p 16∶9 1∶1 148.5 60 67.5 1920 1080 2200 1125 60
17 576p 4∶3 16∶15 27 50 31.25 720 576 864 625 50
18 576pH 16∶9 64∶45 27 50 31.25 720 576 864 625 50
19 720p50 16∶9 1∶1 74.25 50 37.5 1280 720 1980 750 50
20 1080i25 16∶9 1∶1 74.25 50 28.125 1920 540 2640 562.5 50
21 576i 4∶3 16∶15 27 50 15.625 1440 288 1728 312.5 50
22 576iH 16∶9 64∶45 27 50 15.625 1440 288 1728 312.5 50
23 288p 4∶3 8∶15 27 50 15.625 1440 288 1728 313 50
24 288pH 16∶9 32∶45 27 50 15.625 1440 288 1728 313 50
25 576i4x 4∶3 2:15-20:15 54 50 15.625 2880 288 3456 312.5 50
26 576i4xH 16∶9 16:45-160:45 54 50 15.625 2880 288 3456 312.5 50
27 288p4x 4∶3 1:15-10:15 54 50 15.625 2880 288 3456 313 50
28 288p4xH 16∶9 8:45-80:45 54 50 15.625 2880 288 3456 313 50
29 576p2x 4∶3 8:15, 16∶15 54 50 31.25 1440 576 1728 625 50
30 576p2xH 16∶9 32:45, 64∶45 54 50 31.25 1440 576 1728 625 50
31 1080p50 16∶9 1∶1 148.5 50 56.25 1920 1080 2640 1125 50
32 1080p24 16∶9 1∶1 74.25 23.98/24 27 1920 1080 2750 1125 Low
33 1080p25 16∶9 1∶1 74.25 25 28.125 1920 1080 2640 1125 Low
34 1080p30 16∶9 1∶1 74.25 29.97/30 33.75 1920 1080 2200 1125 Low
35 480p4x 4∶3 2:9, 4:9, 8∶9 108 59.94 31.469 2880 240 3432 262.5 60
36 480p4xH 16∶9 8:27, 16:27, 32∶27 108 59.94 31.469 2880 240 3432 262.5 60
37 576p4x 4∶3 4:15, 8:15, 16∶15 108 50 31.25 2880 576 3456 625 50
38 576p4xH 16∶9 16:45, 32:45, 64∶45 108 50 31.25 2880 576 3456 625 50
39 1080i25 16∶9 1∶1 72 50 31.25 1920 540 2304 625 50
40 1080i50 16∶9 1∶1 148.5 100 56.25 1920 540 2640 562.5 100
41 720p100 16∶9 1∶1 148.5 100 45.0 1280 720 1980 750 100
42 576p100 4∶3 16∶15 54 100 62.5 720 576 864 625 100
43 576p100H 16∶9 64∶45 54 100 62.5 720 576 864 625 100
44 576i50 4∶3 16∶15 54 100 31.25 1440 576 1728 625 100
45 576i50H 16∶9 64∶45 54 100 31.25 1440 576 1728 625 100
46 1080i60 16∶9 1∶1 148.5 119.88/120 67.5 1920 540 2200 562.5 120
47 720p120 16∶9 1∶1 148.5 119.88/120 90.0 1280 720 1650 750 120
48 480p119 4∶3 8∶9 54 119.88/120 62.937 720 480 858 525 120
49 480p119H 16∶9 32∶27 54 119.88/120 62.937 720 480 858 525 120
50 480i59 4∶3 16∶15 54 119.88/120 31.469 1440 480 1716 525 120
51 480i59H 16∶9 64∶45 54 119.88/120 31.469 1440 480 1716 525 120
52 576p200 4∶3 16∶15 108 200 125.0 720 576 864 625 200
53 576p200H 16∶9 64∶45 108 200 125.0 720 576 864 625 200
54 576i100 4∶3 16∶15 108 200 62.5 1440 288 1728 312.5 200
55 576i100H 16∶9 64∶45 108 200 62.5 1440 288 1728 312.5 200
56 480p239 4∶3 8∶9 108 239.76 125.874 720 480 858 525 240
57 480p239H 16∶9 32∶27 108 239.76 125.874 720 480 858 525 240
58 480i119 4∶3 8∶9 108 239.76 62.937 1440 240 1716 262.5 240
59 480i119H 16∶9 32∶27 108 239.76 62.937 1440 240 1716 262.5 240
60 720p24 16∶9 1∶1 59.4 23.98/24 18.0 1280 720 3300 750 Low
61 720p25 16∶9 1∶1 74.25 25 18.75 1280 720 3960 750 Low
62 720p30 16∶9 1∶1 74.25 29.97/30 22.5 1280 720 3300 750 Low
63 1080p120 16∶9 1∶1 297 119.88/120 135.0 1920 1080 2200 1125 120
64 1080p100 16∶9 1∶1 297 100 112.5 1920 1080 2640 1125 100
65 720p24 64∶27 4∶3 59.4 23.98/24 18.0 1280 720 3300 750 Low
66 720p25 64∶27 4∶3 74.25 25 18.75 1280 720 3960 750 Low
67 720p30 64∶27 4∶3 74.25 29.97/30 22.5 1280 720 3300 750 Low
68 720p50 64∶27 4∶3 74.25 50 37.5 1280 720 1980 750 50
69 720p 64∶27 4∶3 74.25 60 45.0 1280 720 1650 750 60
70 720p100 64∶27 4∶3 148.5 100 75.0 1280 720 1980 750 100
71 720p120 64∶27 4∶3 148.5 119.88/120 90.0 1280 720 1650 750 120
72 1080p24 64∶27 4∶3 74.25 23.98/24 27 1920 1080 2750 1125 Low
73 1080p25 64∶27 4∶3 74.25 25 28.125 1920 1080 2640 1125 Low
74 1080p30 64∶27 4∶3 74.25 29.97/30 33.75 1920 1080 2200 1125 Low
75 1080p50 64∶27 4∶3 148.5 50 56.25 1920 1080 2640 1125 50
76 1080p 64∶27 4∶3 148.5 60 67.5 1920 1080 2200 1125 60
77 1080p100 64∶27 4∶3 297.0 100 112.5 1920 1080 2640 1125 100
78 1080p120 64∶27 4∶3 297.0 119.88/120 135.0 1920 1080 2200 1125 120
79 720p2x24 64∶27 64∶63 59.4 23.98/24 18.0 1680 720 3300 750 Low
80 720p2x25 64∶27 64∶63 59.4 25 18.75 1680 720 3168 750 Low
81 720p2x30 64∶27 64∶63 59.4 29.97/30 22.5 1680 720 2640 750 Low
82 720p2x50 64∶27 64∶63 82.5 50 37.5 1680 720 2200 750 50
83 720p2x 64∶27 64∶63 99 60 45.0 1680 720 2200 750 60
84 720p2x100 64∶27 64∶63 165 100 82.5 1680 720 2000 825 100
85 720p2x120 64∶27 64∶63 198 119.88/120 99.0 1680 720 2000 825 120
86 1080p2x24 64∶27 1∶1 99 23.98/24 26.4 2560 1080 3750 1100 Low
87 1080p2x25 64∶27 1∶1 90 25 28.125 2560 1080 3200 1125 Low
88 1080p2x30 64∶27 1∶1 118.8 29.97/30 33.75 2560 1080 3520 1125 Low
89 1080p2x50 64∶27 1∶1 185.625 50 56.25 2560 1080 3000 1125 50
90 1080p2x 64∶27 1∶1 198 60 66.0 2560 1080 3000 1100 60
91 1080p2x100 64∶27 1∶1 371.25 100 125.0 2560 1080 2970 1250 100
92 1080p2x120 64∶27 1∶1 495 119.88/120 150.0 2560 1080 3300 1250 120
93 2160p24 16∶9 1∶1 297 23.98/24 54 3840 2160 5500 2250 Low
94 2160p25 16∶9 1∶1 297 25 56.25 3840 2160 5280 2250 Low
95 2160p30 16∶9 1∶1 297 29.97/30 67.5 3840 2160 4400 2250 Low
96 2160p50 16∶9 1∶1 594 50 112.5 3840 2160 5280 2250 50
97 2160p60 16∶9 1∶1 594 60 135.0 3840 2160 4400 2250 60
98 2160p24 256∶135 1∶1 297 23.98/24 67.5 4096 2160 5500 2250 Low
99 2160p25 256∶135 1∶1 297 25 112.5 4096 2160 5280 2250 Low
100 2160p30 256∶135 1∶1 297 29.97/30 135.0 4096 2160 4400 2250 Low
101 2160p50 256∶135 1∶1 594 50 112.5 4096 2160 5280 2250 50
102 2160p 256∶135 1∶1 594 60 135.0 4096 2160 4400 2250 60
103 2160p24 64∶27 4∶3 297 23.98/24 67.5 3840 2160 5500 2250 Low
104 2160p25 64∶27 4∶3 297 25 112.5 3840 2160 5280 2250 Low
105 2160p30 64∶27 4∶3 297 29.97/30 135.0 3840 2160 4400 2250 Low
106 2160p50 64∶27 4∶3 594 50 112.5 3840 2160 5280 2250 50
107 2160p 64∶27 4∶3 594 60 135.0 3840 2160 4400 2250 60
108 720p48 16∶9 1∶1 90 47.96/48 36.0 1280 720 2500 750 Low
109 720p48 64∶27 4∶3 90 47.96/48 36.0 1280 720 2500 750 Low
110 720p2x48 64∶27 64∶63 99 47.96/48 36.0 1680 720 2750 825 Low
111 1080p48 16∶9 1∶1 148.5 47.96/48 54 1920 1080 2750 1125 Low
112 1080p48 64∶27 4∶3 148.5 47.96/48 54 1920 1080 2750 1125 Low
113 1080p2x48 64∶27 1∶1 198 47.96/48 52.8 2560 1080 3750 1100 Low
114 2160p48 16∶9 1∶1 594 47.96/48 108 3840 2160 5500 2250 Low
115 2160p48 256∶135 1∶1 594 47.96/48 108 4096 2160 5500 2250 Low
116 2160p48 64∶27 4∶3 594 47.96/48 108 3840 2160 5500 2250 Low
117 2160p100 16∶9 1∶1 1188 100 225.0 3840 2160 5280 2250 100
118 2160p120 16∶9 1∶1 1188 119.88/120 270.0 3840 2160 4400 2250 120
119 2160p100 64∶27 4∶3 1188 100 225.0 3840 2160 5280 2250 100
120 2160p120 64∶27 4∶3 1188 119.88/120 270.0 3840 2160 4400 2250 120
121 2160p2x24 64∶27 1∶1 396 23.98/24 52.8 5120 2160 7500 2200 Low
122 2160p2x25 64∶27 1∶1 396 25 55.0 5120 2160 7200 2200 Low
123 2160p2x30 64∶27 1∶1 396 29.97/30 66.0 5120 2160 6000 2200 Low
124 2160p2x48 64∶27 1∶1 742.5 47.96/48 118.8 5120 2160 6250 2450 Low
125 2160p2x50 64∶27 1∶1 742.5 50 112.5 5120 2160 6600 2250 50
126 2160p2x 64∶27 1∶1 742.5 60 135.0 5120 2160 5500 2250 60
127 2160p2x100 64∶27 1∶1 1485 100 225.0 5120 2160 6600 2250 100
129—192 reserved, value range is used in SVD to indicate native timing for numbers 1—64.
193 2160p2x120 64∶27 1∶1 1485.0 119.88/120 270 5120 2160 5500 2250 120
194 4320p24 16∶9 1∶1 1188.0 23.98/24 108 7680 4320 11000 4500 Low
195 4320p25 16∶9 1∶1 1188.0 25 110 7680 4320 10800 4400 Low
196 4320p30 16∶9 1∶1 1188.0 29.97/30 132 7680 4320 9000 4400 Low
197 4320p48 16∶9 1∶1 2376.0 47.96/48 216 7680 4320 11000 4500 Low
198 4320p50 16∶9 1∶1 2376.0 50 220 7680 4320 10800 4400 50
199 4320p 16∶9 1∶1 2376.0 60 264 7680 4320 9000 4400 60
200 4320p100 16∶9 1∶1 4752.0 100 450 7680 4320 10560 4500 100
201 4320p120 16∶9 1∶1 4752.0 119.88/120 540 7680 4320 8800 4500 120
202 4320p24 64∶27 4∶3 1188.0 23.98/24 108 7680 4320 11000 4500 Low
203 4320p25 64∶27 4∶3 1188.0 25 110 7680 4320 10800 4400 Low
204 4320p30 64∶27 4∶3 1188.0 29.97/30 132 7680 4320 9000 4400 Low
205 4320p48 64∶27 4∶3 2376.0 47.96/48 216 7680 4320 11000 4500 Low
206 4320p50 64∶27 4∶3 2376.0 50 220 7680 4320 10800 4400 50
207 4320p 64∶27 4∶3 2376.0 60 264 7680 4320 9000 4400 60
208 4320p100 64∶27 4∶3 4752.0 100 450 7680 4320 10560 4500 100
209 4320p120 64∶27 4∶3 4752.0 119.88/120 540 7680 4320 8800 4500 120
210 4320p2x24 64∶27 1∶1 1485.0 23.98/24 118.8 10240 4320 12500 4950 Low
211 4320p2x25 64∶27 1∶1 1485.0 25 110 10240 4320 13500 4400 Low
212 4320p2x30 64∶27 1∶1 1485.0 29.97/30 135 10240 4320 11000 4500 Low
213 4320p2x48 64∶27 1∶1 2970.0 47.96/48 237.6 10240 4320 12500 4950 Low
214 4320p2x50 64∶27 1∶1 2970.0 50 220 10240 4320 13500 4400 50
215 4320p2x 64∶27 1∶1 2970.0 60 270 10240 4320 11000 4400 60
216 4320p2x100 64∶27 1∶1 5940.0 100 450 10240 4320 13200 4500 100
217 4320p2x120 64∶27 1∶1 5940.0 119.88/120 540 10240 4320 11000 4500 120
218 2160p100 256∶135 1∶1 1188.0 100 225 4096 2160 5280 2250 100
219 2160p120 256∶135 1∶1 1188.0 119.88/120 270 4096 2160 4400 2250 120

Notes: Parentheses indicate instances where pixels are repeated to meet the minimum speed requirements of the interface. For example, in the 720x240p case, the pixels on each line are double-clocked. In the (2880)x480i case, the number of pixels on each line, and thus the number of times that they are repeated, is variable, and is sent to the DTV monitor by the source device.

Increased Hactive expressions include “2x” and “4x” indicate two and four times the reference resolution, respectively.

Video modes with vertical refresh frequency being a multiple of 6 Hz (i.e. 24, 30, 60, 120, and 240 Hz) are considered to be the same timing as equivalent NTSC modes where vertical refresh is adjusted by a factor of 1000/1001. As VESA DMT specifies 0.5% pixel clock tolerance, which 5 times more than the required change, pixel clocks can be adjusted to maintain NTSC compatibility; typically, 240p, 480p, and 480i modes are adjusted, while 576p, 576i and HDTV formats are not.

  • The EIA/CEA-861 and 861-A standards included only numbers 1–7 and numbers 17–22 (only in -A) above (but not as short video descriptors which were introduced in EIA/CEA-861-B) and are considered primary video format timings.
  • The EIA/CEA-861-B standard has the first 34 short video descriptors above. It is used by HDMI 1.0–1.2a.
  • The EIA/CEA-861-C and -D standards have the first 59 short video descriptors above. EIA/CEA-861-D is used by HDMI 1.3–1.3c.
  • The EIA/CEA-861-E standard has the first 64 short video descriptors above. It is used by HDMI 1.4–1.4b.
  • The CTA-861-F standard has the first 107 short video descriptors above. It is used by HDMI 2.0–2.0b.
  • The CTA-861-G standard has the full list of 154 (1–127, 193–219) short video descriptors above. It is used by HDMI 2.1.

Audio Data Blocks

[edit]

The Audio Data Blocks contain one or more 3-byte Short Audio Descriptors (SADs). Each SAD details audio format, channel number, and bitrate/resolution capabilities of the display as follows:

Short Audio Descriptor
Byte Description
0 Data block header
1 Format and number of channels:
Bit 7 Reserved, 0
Bit 6–3 Audio format code
Bit 2–0 Number of channels minus 1
  • 000 1 channel
  • 001 2 channels
  • 010 3 channels
  • 011 4 channels
  • 100 5 channels
  • 101 6 channels
  • 110 7 channels
  • 111 8 channels
2 Sampling frequencies (kHz) supported:
Bit 7 Reserved, 0
Bit 6 192
Bit 5 176
Bit 4 96
Bit 3 88
Bit 2 48
Bit 1 44.1
Bit 0 32
3 Bitrate / format dependent:
For codec 1, LPCM:
Bits 7–3 Reserved
Bit 2 24-bit depth
Bit 1 20-bit depth
Bit 0 16-bit depth
For audio format codecs 2–8, the maximum supported bitrate in bit/s, divided by 8000.
For audio format codecs 9–14, format dependent value.
For audio format codec 15 (Extension):
Bit 7–3 Audio format extended code
Bits 2–0 format dependent value

Vendor Specific Data Block

[edit]

A Vendor Specific Data Block (if any) contains as its first three bytes the vendor's IEEE 24-bit registration number,[24] least significant byte first. The remainder of the Vendor Specific Data Block is the "data payload", which can be anything the vendor considers worthy of inclusion in this EDID extension block. For example, IEEE registration number 00 0C 03 means this is a "HDMI Licensing, LLC" specific data block (contains HDMI 1.4 info), C4 5D D8 means this is a "HDMI Forum" specific data block (contains HDMI 2.0 info), 00 D0 46 means this is "DOLBY LABORATORIES, INC." (contains Dolby Vision info) and 90 84 8b is "HDR10+ Technologies, LLC" (contains HDR10+ info as part of HDMI 2.1 Amendment A1 standard[25]). It starts with a two byte source physical address, least significant byte first. The source physical address provides the CEC physical address for upstream CEC devices. HDMI 1.3a specifies some requirements for the data payload.

Vendor Specific Data Block for "HDMI Licensing LLC"
Byte Description
0 Data block header
1–3 IEEE Registration Identifier (little endian)
4–5 Components of Source Physical Address[26]
6 (optional) 1, supported; 0, unsupported:
Bit 7 A function that needs info from ACP or ISRC packets
Bit 6 16-bit-per-channel deep color (48-bit)
Bit 5 12-bit-per-channel deep color (36-bit)
Bit 4 10-bit-per-channel deep color (30-bit)
Bit 3 4∶4∶4 in deep color modes
Bit 2 Reserved, 0
Bit 1 Reserved, 0
Bit 0 DVI Dual Link Operation
7 (optional) Maximum TMDS frequency. 0, unspecified; else, Max_TMDS_Frequency / 5 MHz
8 (optional) Latency fields indicators 1, present; 0, absent:
Bit 7 Latency fields
Bit 6 Interlaced latency fields. Absent if latency fields are absent.
Bits 5–0 Reserved, 0
9 Video latency optional; if indicated, value = 1 + ms/2 with a max. of 251 meaning 500 ms
10 Audio latency
(video delay for progressive sources)
11 Interlaced video latency
12 Interlaced audio latency
(video delay for interlaced sources)
13+ Additional bytes may be present, but the HDMI spec. says they shall be 00.

Speaker Allocation Data Block

[edit]

If a Speaker Allocation Data Block is present, it will consist of three bytes. The first and second bytes contain information about which speakers (or speaker pairs) are present in the display device:

Speaker Allocation Data Block
Byte Description
0 Data block header
1 1, present; 0, absent:
Bit 7 Front left/right wide (FLw/FRw)
Bit 6 Deprecated, was Rear left/right center (RLC/RRC)
Bit 5 Front left/right center (FLc/FRc)
Bit 4 Back center (BC)
Bit 3 Back left/right (BL/BR)
Bit 2 Front center (FC)
Bit 1 Low-frequency effects (LFE)
Bit 0 Front left/right (FL/FR)
2
Bit 7 Deprecated, was Top side left/right (TpSiL/TpSiR)
Bit 6 Deprecated, was Side left/right (SiL/SiR)
Bit 5 Deprecated, was Top back center (TpBC)
Bit 4 Deprecated, was Low-frequency effects 2 (LFE2)
Bit 3 Left surround/right surround (LS/RS)
Bit 2 Top front center (TpFC)
Bit 1 Top center (TpC)
Bit 0 Top front left/right (TpFL/TpFR)
3 Bits 7-3 Reserved, 0
Bit 2 Deprecated, was Bottom front left/right (BtFL/BtFR)
Bit 1 Deprecated, was Bottom front center (BtFC)
Bit 0 Deprecated, was Top back left/right (TpBL/TpBR)

Some speaker flags have been deprecated in the SADB, but are still available in the RCDB's SPM. These speakers could not be indicated with a CA value in the Audio InfoFrame, and can only be used with Delivery According to the Speaker Mask, which corresponds to the RCDB only.

Room Configuration Data Block

[edit]

The Room Configuration Data Block and Speaker Location Data Blocks describe the speaker setup using room coordinates.

Room Configuration Data Block
Byte Description
0 Data block header
Bits 7-5 111=7, block type tag
Bits 4-0 Length of payload data that follows this block, in bytes
1 13 = extended tag code
3 Configuration
Bit 7 Display data is valid
Bit 6 Speaker count is valid
Bit 5 Speaker location descriptors (SLD) are present
Bits 4-0 Speaker count (1-32)
4 Speaker presence mask 1 (SPM1): 1, present; 0, absent
Bit 7 Front left/right wide (FLw/FRw)
Bit 6 Deprecated, was Rear left/right center (RLC/RRC)
Bit 5 Front left/right center (FLc/FRc)
Bit 4 Back center (BC)
Bit 3 Back left/right (BL/BR)
Bit 2 Front center (FC)
Bit 1 Low-frequency effects 1 (LFE1)
Bit 0 Front left/right (FL/FR)
5 Speaker presence mask 2 (SPM2): 1, present; 0, absent
Bit 7 Top side left/right (TpSiL/TpSiR)
Bit 6 Side left/right (SiL/SiR)
Bit 5 Top back center (TpBC)
Bit 4 Low-frequency effects 2 (LFE2)
Bit 3 Left/right surround (LS/RS)
Bit 2 Top front center (TpFC)
Bit 1 Top center (TpC)
Bit 0 Top front left/right (TpFL/TpFR)
6 Speaker presence mask 3 (SPM3): 1, present; 0, absent
Bits 7-4 Reserved, 0
Bit 3 Deprecated, was Top left/right surround (TpLS/TpRS)
Bit 2 Bottom front left/right (BtFL/BtFR)
Bit 1 Bottom front center (BtFC)
Bit 0 Top back left/right (TpBL/TpBR)
7-9 Maximum distance from the primary listening position to the farthest speakers along X, Y, Z axes, if speaker location descriptors (SLD) blocks are present; otherwise 00 = undefined
10-13 Distance from the primary listening position to the center of display along X, Y, Z axes; 00 = undefined when display data flag is not set

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Extended Display Identification Data

View on Grokipedia
from Grokipedia
Extended Display Identification Data (EDID) is a standardized data structure developed by the Video Electronics Standards Association (VESA) that enables video display devices, such as monitors and televisions, to communicate their technical capabilities—including supported resolutions, refresh rates, color formats, and manufacturer details—to a connected video source like a graphics card or media player via the Display Data Channel (DDC).[1][2] This bidirectional communication, facilitated by the I²C protocol over DDC lines in interfaces like VGA, DVI, HDMI, and DisplayPort, supports plug-and-play functionality by allowing the source device to automatically configure optimal output settings, thereby ensuring compatibility and preventing issues such as signal mismatches or blank screens.[1][3] The EDID standard originated in 1994 with version 1.0, introduced alongside the initial DDC specification to standardize monitor identification and timing data exchange in an era of increasing display complexity.[1][4] Subsequent revisions addressed evolving needs: version 1.3, released in 2000, incorporated support for widescreen aspect ratios and additional timing descriptors; version 1.4, finalized in 2006 as part of the Enhanced EDID (E-EDID) framework, added comprehensive colorimetry data, including support for xvYCC and sYCC color spaces, along with refined monitor range limits for horizontal and vertical frequencies.[1][5] An interim version 2.0, proposed with a larger 256-byte structure for greater flexibility, was largely deprecated due to compatibility challenges, with VESA instead favoring extensible 128-byte blocks under E-EDID.[2] At its core, EDID consists of a mandatory 128-byte base block (Block 0) stored in the display's non-volatile memory, which outlines fundamental parameters such as the vendor ID (encoded via three-character ASCII codes), product code, serial number, display size, and basic timing information derived from established VESA standards like Generalized Timing Formula (GTF) or Coordinated Video Timings (CVT).[1][5] Optional extension blocks—each also 128 bytes—allow for expanded details, including detailed timing descriptors for specific resolutions (up to four per block), color point data for white and red/green/blue primaries, and vendor-specific extensions like those from the Consumer Electronics Association (CEA) for HDMI audio/video capabilities.[1][2] The structure concludes with checksums to verify data integrity during transmission. EDID's role extends beyond basic identification, influencing modern AV systems by enabling features like multi-monitor setups, hot-plugging, and adaptive syncing technologies, though challenges such as incomplete implementations or EDID corruption can necessitate emulators or management tools for reliable operation.[1] In 2009, VESA introduced DisplayID as a modular successor with variable-length data blocks for broader device support, including consumer electronics, but EDID persists as the dominant format due to its backward compatibility and widespread adoption across legacy and current interfaces.[2][6]

Overview and Purpose

Definition and Core Function

Extended Display Identification Data (EDID) is a standardized 128-byte binary data structure embedded in digital displays, designed to communicate the display's capabilities to a video source device, such as a graphics processing unit (GPU).[5] Published by the Video Electronics Standards Association (VESA), EDID serves as a metadata format that describes essential display characteristics, including supported resolutions, refresh rates, color depth and formats, and—in cases with extensions—audio capabilities.[7] This enables automatic configuration of the video signal for compatibility and optimal performance, supporting plug-and-play interoperability between displays and sources.[3] The primary role of EDID is to inform the source device about the display's operational limits and preferred timings, allowing the GPU to generate an appropriately formatted output signal without requiring user adjustment.[5] For instance, it conveys details on horizontal and vertical pixel counts, frame rates, and pixel encoding schemes to prevent signal mismatches that could result in blank screens or distorted images.[3] EDID evolved from foundational Display Data Channel (DDC) standards to provide a more comprehensive capability exchange.[8] EDID is transmitted from the display to the source during the connection handshake via the Enhanced Display Data Channel (E-DDC), which uses the I²C serial bus protocol at a standard address like 0x50.[5] The source initiates a read request, and the display responds by sending the 128-byte block (or multiple blocks if extensions are present), ensuring the data is accessible immediately upon link establishment.[7] Key elements of the EDID structure include a fixed 8-byte header with the pattern 00 FF FF FF FF FF FF 00 for easy identification, followed by vendor-specific details such as a 3-character Industry Standard Architecture (ISA) code for the manufacturer ID, a 16-bit product code, a 32-bit serial number, and manufacturing timing encoded as week and year values.[5] These identification components allow the source to uniquely recognize the display model and apply tailored settings, while the overall structure concludes with a checksum byte to verify data integrity.[3]

Role in Video Interfaces

Extended Display Identification Data (EDID) integrates with video interfaces primarily through the VESA Display Data Channel (DDC) protocol, which operates over an I²C serial bus to enable the source to read the display's capabilities, with the optional DDC/CI extension providing bidirectional communication for monitor control.[9] The DDC/CI uses specific I²C slave addresses—typically 50h/51h (A0h/A1h) for EDID read operations and 37h for CI commands—to allow the source to query the display's capabilities without interrupting video transmission.[9] This setup supports plug-and-play functionality by ensuring the source can dynamically retrieve and interpret EDID data to configure output signals appropriately.[5] In various interfaces, EDID transmission occurs via dedicated channels: HDMI employs the DDC lines (pins 15 for SCL and 16 for SDA) powered by +5V on pin 18, facilitating EDID exchange alongside TMDS video signals.[9] DisplayPort maps DDC to its bidirectional AUX channel using an I²C-over-AUX protocol, which emulates standard I²C transactions at up to 1 Mbps (or faster in later versions) for EDID reads while handling link training and status.[10] VGA supports EDID optionally over I²C on pins 12 (SDA) and 15 (SCL) with +5V on pin 9, though adoption is less universal due to its analog nature.[9] For USB-C and Thunderbolt, EDID integrates through DisplayPort Alternate Mode or embedded HDMI signaling, leveraging the USB-C connector's SuperSpeed pairs reconfigured for video protocols.[11] The handshake process begins upon device connection, where hot-plug detection—signaled by voltage on dedicated pins (e.g., HPD in HDMI/DisplayPort or +5V in VGA)—prompts the source to query the display's EDID within 20 ms.[9] The base 128-byte EDID block (Block 0) is read first via sequential or random I²C accesses, followed by any extension blocks (up to 255, totaling 32 KB) indicated by a segment pointer register at I²C slave address 0x30 in E-DDC, allowing comprehensive capability reporting.[9] This process ensures reliable signal negotiation, but in setups with extenders, switches, or daisy-chained displays, EDID emulation is often employed to mimic valid data blocks and prevent handshake failures that could result in no signal or black screens.[3] For instance, in an HDMI connection, the source reads the display's EDID to select a supported mode like 4K at 60 Hz with HDR metadata if advertised in the extension blocks, optimizing output without manual configuration.[3]

Historical Development

Origins and Early Standards

The Extended Display Identification Data (EDID) standard originated from efforts by the Video Electronics Standards Association (VESA) to address inconsistencies in monitor capability reporting during the early days of personal computing, where systems often relied on manual configuration or limited interfaces like the VESA BIOS Extension (VBE) for video modes without standardized display feedback.[3] Introduced in 1994 as part of the Display Data Channel (DDC) standard version 1.0, EDID provided a structured method for monitors to convey identification and timing information to graphics adapters via the I²C bus on VGA connectors, enabling more reliable plug-and-play functionality beyond VBE's video adapter focus.[8] This development was influenced by emerging bus standards like EISA and PCI, which emphasized standardized hardware communication in PCs.[12] Version 1.0 of EDID, released in August 1994 within DDC standard version 1.0 revision 0, established the foundational 128-byte binary format stored in a monitor's EEPROM.[8] The structure included a fixed header (bytes 0-7 set to 00h), a manufacturer identifier (bytes 8-9 using three-character codes), product code (bytes 10-11), serial number (bytes 12-15), manufacturing date (bytes 16-17 as week and year), EDID version and revision (bytes 18-19), and timing data encompassing established timings (byte 20 for legacy VESA modes), standard timings (bytes 21-35 for 8x aspect ratio and horizontal pixels), and four detailed timing descriptors (bytes 36-125, each 18 bytes for custom modes or reserved).[12] Version 1.1, introduced in April 1996 via EDID standard version 2 revision 0, built on this by defining previously unused fields in the descriptors and adding support for monitor-specific information such as serial numbers and manufacturing dates in a more robust manner, while maintaining backward compatibility.[8] EDID version 1.2, released in November 1997 under EDID standard version 3, further refined the format by providing additional definitions for existing data fields, including enhanced monitor descriptors within the 18-byte blocks to describe features like range limits, and laying groundwork for extensibility without altering the core 128-byte size.[13] Version 1.3, formalized on February 9, 2000, in the Enhanced EDID (E-EDID) standard release A revision 1, introduced key advancements such as support for LCD-specific timings via new descriptor tags, color point data for chromaticity coordinates, and secondary Generalized Timing Formula (GTF) curve coefficients in the range limits descriptor, while mandating certain descriptors like monitor name and range limits for better interoperability.[8] These early versions up to 1.3 emphasized conceptual standardization for CRT-dominated displays but paved the way for 1.4 enhancements in handling diverse modern panels.[8]

Revision Timeline

The EDID standard reached version 1.4 in September 2006, as part of the VESA Enhanced Extended Display Identification Data (E-EDID) Release A, Revision 2, which expanded the format to support up to four 18-byte descriptors for detailed timing information, introduced Coordinated Video Timings (CVT) support alongside the existing Generalized Timings Formula (GTF), included optional secondary GTF curve parameters in the display range limits, and added 3-byte CVT timing codes for more precise video mode definitions.[5] This revision built on the foundations of earlier versions like 1.3 by enhancing timing flexibility while maintaining backward compatibility, allowing a total structure of up to 256 bytes when including one 128-byte extension block.[5] In 2000, VESA formalized the E-EDID standard to incorporate extension blocks systematically, providing guidelines for adding multiple optional blocks beyond the base 128-byte structure to accommodate evolving display capabilities without altering the core format.[5] Following version 1.4, VESA issued no major revisions to the core EDID format, instead directing development efforts toward specialized extension blocks, such as the Consumer Technology Association (CTA) timing extension under CEA-861, to address modern video interfaces and content types.[14] Microsoft introduced a Vendor Specific Data Block (VSDB) within the EDID extension framework specifically for head-mounted displays (HMDs) and specialized monitors, starting with version 1 for Windows Mixed Reality HMDs in Windows 10 version 1703 (April 2017), with additional versions for non-Microsoft compositors in 2018 and further enhancements in 2020, enabling identification of Windows-specific features like compatibility with mixed reality compositors and desktop integration flags to ensure proper handling in Windows 10 and later versions.[15] VESA continues to maintain EDID 1.4 as a legacy standard for broad compatibility in display interfaces, while actively promoting DisplayID as its successor for supporting higher resolutions, tiled displays, and future-oriented features.[16]

Core EDID Format (Version 1.4)

Overall Structure

The Enhanced Extended Display Identification Data (E-EDID) version 1.4 defines a fixed 128-byte data block that encapsulates a display device's identification and capability information in a standardized format for transmission over video interfaces.[5] This block, known as Block 0, begins with an 8-byte header occupying bytes 0 through 7, consisting of the fixed pattern 00h FFh FFh FFh FFh FFh FFh 00h, which serves to identify the structure as an EDID block.[5] Bytes 8 through 17 provide core identification details: bytes 8-9 encode the manufacturer's name using a 3-character International Standards Association (ISA) code packed into two bytes; bytes 10-11 hold the 16-bit product identification code assigned by the manufacturer; bytes 12-15 contain the optional 32-bit serial number; and bytes 16-17 specify the manufacture week (1-52, or 0 for model year) and year (relative to 1990).[5] Bytes 18-19 specify the EDID structure version (01h) and revision (04h for version 1.4). Bytes 20-23 cover basic display parameters, including video input signal type (byte 20), maximum horizontal and vertical screen size or aspect ratio (byte 21), display transfer characteristic (gamma, byte 22), and feature support such as standby modes and RGB color (byte 23). Bytes 24-34 provide chromaticity data, encoding the red, green, blue, and white point coordinates in fixed-point format for color management.[5] Bytes 35-37 (offsets 0x23-0x25) cover established timings in a 3-byte field, using 19 bits (plus reserved) to indicate support for up to 19 predefined video modes, such as 800×600 at 60 Hz, with byte 37 including one additional mode plus reserved bits for manufacturer-specific timings.[5] Bytes 38-53 (offsets 0x26-0x35) then detail standard timings across eight 2-byte blocks, each specifying horizontal and vertical pixel counts, aspect ratio, and a refresh rate range multiplier.[5] The bulk of the timing and capability data resides in bytes 54-125 (offsets 0x36-0x7D), organized into four 18-byte descriptor blocks that report detailed video timings, monitor characteristics, or other attributes to convey the display's operational limits.[5] These descriptors play a key role in reporting the display's supported resolutions and features to the connected source device. Finally, bytes 126-127 include the extension flag (byte 126, indicating the number of optional 128-byte extension blocks that follow) and the checksum (byte 127, ensuring the sum of all 128 bytes equals 0 modulo 256 for data integrity).[5] Extension blocks, if present, each begin with a tag byte (such as 02h for the CEA extension) followed by a version byte, allowing for additional standardized data structures beyond the base block.[5]

Header and Identifier Blocks

The header of the EDID 1.4 structure occupies bytes 0 through 7 and consists of a fixed byte sequence: 00h followed by six FFh bytes and concluding with 00h.[5] This pattern serves as a unique identifier to signal the presence of a valid EDID block, distinguishing it from raw Display Data Channel (DDC) data or other non-EDID content transmitted over the interface.[5] It ensures that source devices, such as graphics cards or media players, can reliably detect and parse the structure during initialization.[5] Immediately following the header, bytes 8 through 17 form the vendor identification block, which provides essential details for uniquely recognizing the display device.[5] Bytes 8 and 9 encode the manufacturer's three-character ASCII name using a compressed 5-bit code format derived from the EISA PnP ID scheme, where each character (A-Z) maps to values 1 through 26, packed into 10 bits across the two bytes with the most significant bit of each nibble set to zero.[5] For example, the code for "SAM" (Samsung) would be represented as 0xDAh in byte 8 and 0x4Dh in byte 9.[5] Bytes 10 and 11 specify a 16-bit product code assigned by the manufacturer, stored in little-endian order (least significant byte first), allowing differentiation among models from the same vendor.[5] Bytes 12 through 15 hold a 32-bit serial number, also in little-endian format, ranging from 0 to 4,294,967,295, which may be omitted (set to all zeros) if not used by the manufacturer.[5] The identification block concludes with manufacturing timing data in bytes 16 and 17.[5] Byte 16 indicates the week of manufacture as an 8-bit value from 1 to 52 (or 53/54 for leap years), with 0x00 denoting unspecified or reserved for model year usage; if set to 0xFF, it signals that byte 17 represents a model year rather than a manufacture year.[5] Byte 17 provides the year as an 8-bit offset from 1990 (e.g., 0x11 for 2001), supporting dates up to 2245, or the model year if flagged accordingly.[5] Together, these fields enable source devices to uniquely identify the display, cache its capabilities for subsequent connections, and support features like firmware updates or inventory tracking without re-querying the full EDID.[5] Byte 126, known as the extension flag, is an 8-bit unsigned integer (0x00 to 0xFF) that specifies the number of optional 128-byte extension blocks appended after the base EDID structure.[5] A value of 0x00 indicates a basic EDID without extensions, while higher values (up to 0xFE or 0xFF, depending on block map usage) denote enhanced EDID (E-EDID) with additional data such as CTA-861 timings or color management.[5] This byte allows sources to determine the total data length and process extensions sequentially for comprehensive display configuration.[5] The final byte, 127, is the checksum, an 8-bit value (0x00 to 0xFF) calculated such that the sum of all 128 bytes in the block equals 0 modulo 256.[5] It provides a simple integrity check against transmission errors or tampering; sources must recompute the sum upon receipt, and any mismatch invalidates the block, prompting retries or fallback modes.[5] This mechanism ensures reliable delivery of identification and capability data over the DDC bus.[5]

Established Timings and Standard Timings

The established timings block in the EDID 1.4 structure provides a compact bitmap representation of support for predefined VESA Display Monitor Timings (DMT), allowing displays to signal compatibility with common legacy and standard video modes without requiring detailed descriptors.[5] This block occupies three bytes (offsets 0x23 to 0x25), forming a 24-bit field where each bit set to 1 indicates factory-tested support for a specific timing, ensuring the image is properly sized and centered on the display.[5] The first two bytes cover 16 standard VESA modes, while the third byte includes one additional mode plus reserved bits for manufacturer-specific timings.[5] Representative examples from the bitmap include bit 0 of the first byte (offset 0x23, bit 0) for 720 × 400 at 70 Hz, bit 5 for 640 × 480 at 60 Hz, and bit 7 for 1024 × 768 at 60 Hz; in the second byte (offset 0x24), bit 7 supports 800 × 600 at 72 Hz, and bit 0 supports 1280 × 1024 at 75 Hz; the third byte (offset 0x25) has bit 7 for 800 × 600 at 56 Hz, with bits 6-0 reserved or for proprietary use.[5] In EDID 1.4, an optional Established Timings III descriptor (tag F7h in one of the 18-byte descriptor blocks) extends this with bit flags for up to 44 additional modes from the VESA DMT standard, such as 1280 × 1024 at 60 Hz (bit 4 of the first byte in the descriptor), further enhancing support for higher resolutions.[5] These timings prioritize well-known VESA standards, enabling graphics sources to quickly select compatible modes from a shared set of up to 25 predefined options (17 base established plus 8 from the extension) plus more via the III descriptor.[5] The standard timings block follows immediately, spanning 16 bytes (offsets 0x26 to 0x35) for eight 2-byte entries that define additional common timings beyond the established bitmap, ordered by priority with the first entry often indicating the preferred mode.[5] Each entry's first byte specifies the horizontal active pixels H using the formula H=8×(V+31)H = 8 \times (V + 31), where VV is the byte value (ranging from 0x01 to 0xB3 for H from 256 to 1680 pixels); unused entries are padded with 0x01 0x01.[5] For example, V=0x31V = 0x31 (49 decimal) yields H=8×(49+31)=640H = 8 \times (49 + 31) = 640 pixels, while V=0x45V = 0x45 gives 800 pixels, V=0x61V = 0x61 gives 1024 pixels, and V=0x81V = 0x81 gives 1280 pixels.[5] The second byte of each entry encodes the aspect ratio in bits 7-6 (00 binary for 16:10, 01 for 4:3, 10 for 5:4, 11 for 16:9) and the vertical refresh rate in bits 5-0 as a code RR where the rate is 60+R60 + R Hz (ranging from 60 Hz for R=0R=0 to 123 Hz for R=63R=63).[5] For instance, a second byte of 0x40 (binary 0100 0000) indicates 4:3 aspect at 60 Hz, while 0xC1 (binary 1100 0001) specifies 16:9 at 61 Hz.[5] Together, the established and standard timings allow sources to negotiate up to 25 common modes efficiently, with custom timings available through detailed descriptors for non-standard requirements.[5]

Detailed Timing Descriptors

Detailed Timing Descriptors in the EDID 1.4 main block provide a mechanism for specifying custom video timings beyond the predefined established and standard timings, enabling support for preferred or non-standard display modes. Each descriptor occupies an 18-byte block, with up to four such blocks available in the 128-byte EDID structure, typically located at offsets 36h–47h, 48h–59h, 5Ah–6Bh, and 6Ch–7Dh. The first descriptor often represents the preferred timing mode, which is the native resolution and refresh rate optimized for the display. These descriptors allow precise definition of pixel clock, active and blanking periods, synchronization parameters, and additional attributes like image size and sync polarities, facilitating compatibility with diverse video interfaces such as VGA, DVI, and HDMI.[5] The format of each 18-byte block is structured as follows, with all multi-byte values stored in little-endian order:
ByteDescriptionDetails
0-1Pixel Clock16-bit value representing the clock frequency in units of 10 kHz (divided by 10 for MHz). For example, 0258h (600 decimal) corresponds to 60 MHz, commonly used for 1024×768 resolution at 60 Hz. Range: 10 kHz to 6553.5 MHz.
2Horizontal Active Video (low 8 bits)Lower 8 bits of the horizontal active pixels.
3Horizontal Blanking (low 8 bits)Lower 8 bits of the horizontal blanking pixels.
4Horizontal Active Video (high 4 bits) + Horizontal Blanking (high 4 bits)Bits 7–4: high 4 bits of horizontal active; bits 3–0: high 4 bits of horizontal blanking. Full horizontal active = (byte 4 >> 4 << 8) | byte 2; full blanking similarly.
5Vertical Active Video (low 8 bits)Lower 8 bits of vertical active lines.
6Vertical Blanking (low 8 bits)Lower 8 bits of vertical blanking lines.
7Vertical Active Video (high 4 bits) + Vertical Blanking (high 4 bits)Bits 7–4: high 4 bits of vertical active; bits 3–0: high 4 bits of vertical blanking.
8Horizontal Sync Offset (low 8 bits)Lower 8 bits of the offset from active video to sync start.
9Horizontal Sync Pulse Width (low 8 bits)Lower 8 bits of horizontal sync duration.
10Vertical Sync Pulse Width (high 4 bits) + Vertical Sync Offset (low 4 bits)Bits 7–4: vertical sync pulse width (lower 4 bits); bits 3–0: vertical sync offset (lower 4 bits).
11Horizontal/Vertical Sync High BitsBits 7–6: H sync offset high 2 bits; bits 5–4: H sync pulse high 2 bits; bits 3–2: V sync offset high 2 bits; bits 1–0: V sync pulse high 2 bits.
12Horizontal Image Size (low 8 bits)Lower 8 bits of horizontal image size (in cm/10 or %).
13Vertical Image Size (low 8 bits)Lower 8 bits of vertical image size (in cm/10 or %).
14Horizontal Image Size (high 4 bits) + Vertical Image Size (high 4 bits)Bits 7–4: high 4 bits of horizontal image size; bits 3–0: high 4 bits of vertical image size. If byte 14 = 00h and bytes 12-13 indicate no size, aspect ratio is encoded instead.
15Horizontal BorderHorizontal border size in pixels (typically 0 for modern displays).
16Vertical BorderVertical border size in lines (typically 0).
17FlagsBit-level attributes for timing characteristics (detailed below).
To derive key timing parameters, calculations are performed on the extracted values. For instance, the horizontal total pixels is computed as horizontal active pixels plus horizontal blanking pixels. The horizontal sync start position is then horizontal active plus horizontal sync offset. Similarly, vertical total lines = vertical active lines + vertical blanking lines, and vertical sync start = vertical active + vertical sync offset. These computations ensure the source device can generate signals matching the display's requirements; for a 1024×768@60 Hz mode, horizontal active might be 1024 pixels, blanking 320 pixels (total 1344), with sync offset of 160 pixels, yielding sync start at 1184 pixels. If no detailed descriptors are present or applicable, the display falls back to predefined timings.[5] The flags byte (byte 17) encodes several binary attributes in its bits:
  • Bit 7: Interlaced (1 = interlaced mode, 0 = progressive/non-interlaced).
  • Bits 6–5: Stereo viewing support (00 = no stereo; 01 = field sequential right image when viewed from left; 10 = field sequential left image when viewed from right; 11 = 4-way interleaved or side-by-side).
  • Bit 4: Sync signal type (1 = separate horizontal and vertical syncs; 0 = analog composite sync on HSync).
  • Bit 3: Vertical sync polarity (1 = positive, 0 = negative).
  • Bit 2: Horizontal sync polarity (1 = positive, 0 = negative).
  • Bits 1–0: Reserved (must be 00).
These flags allow fine-tuned control over signal generation, ensuring compatibility with various sync schemes and viewing modes, such as separate sync for digital interfaces or composite for legacy analog. In EDID 1.4, the image size fields in bytes 12–14 can alternatively specify aspect ratios (e.g., 16:9) if set to 0 in the high nibbles of byte 14, providing flexibility for DTV modes without physical size data.[5]

Monitor Name and Range Limit Descriptors

In the EDID 1.4 format, the Monitor Name Descriptor occupies an 18-byte block within one of the four descriptor fields, typically used to provide a human-readable identifier for the display device. This descriptor is identified by tag 0xFC at byte 2, with bytes 0 and 1 set to 00h, byte 3 set to 00h, and bytes 5 through 17 containing an ASCII-encoded string of up to 13 characters for the monitor name, padded with spaces (0x20h) if necessary and often terminated with a line feed (0x0Ah); byte 4 is unused (00h). For instance, the name "Samsung SyncMaster" would be represented by the corresponding ASCII values in these bytes, enabling operating systems and applications to display the model name to users. Although optional in EDID 1.4, this descriptor is recommended to facilitate device recognition and troubleshooting.[5] The Monitor Range Limits Descriptor, also an 18-byte block tagged with 0xFD at byte 2 (with bytes 0 and 1 as 00h), specifies the display's supported frequency ranges and maximum pixel clock to guide video sources in generating compatible timings. Byte 3 encodes the minimum vertical refresh rate in Hz (values 00h–FFh, potentially offset by up to 768 Hz via flags in byte 8), byte 4 the maximum vertical rate, byte 5 the minimum horizontal scan rate in kHz (similarly offsettable), byte 6 the maximum horizontal rate, and byte 7 the maximum supported pixel clock as clock rate in MHz / 10 (e.g., 0Dh for 130 MHz, rounded to nearest 10 MHz). Byte 8 contains flags for rate offsets (bits 3–2 for vertical, bits 1–0 for horizontal) and GTF support (bit 7 traditionally for basic GTF, though extended in 1.4), while byte 9 indicates the timing support type: 00h for default GTF, 01h for range limits only, 02h for secondary GTF, 03h for both GTF variants, or 04h for CVT support. Bytes 10–17 are reserved (00h) unless secondary GTF is indicated, in which case they store curve parameters including the start break frequency (byte 11, in kHz/2), C coefficient ×2 (byte 12), M coefficient (bytes 13–14, little-endian), K (byte 15), and J coefficient ×2 (byte 16), with byte 17 often set to 0x0Ah. This descriptor is optional but recommended for monitors supporting continuous frequencies, allowing sources to apply the Generalized Timing Formula (GTF) to derive timings when detailed or standard timings are absent; GTF compliance is signaled by the continuous frequency bit (bit 3 of byte 17h in the main EDID block). The GTF enables timing generation via equations adjusting blanking duty cycles based on frequency, such as scaling factors involving C and J for vertical total calculations relative to pixel clock and horizontal totals.[5][17]

Advanced Descriptors in EDID 1.4

Display Range Limits

The Display Range Limits descriptor in EDID 1.4 specifies the operational boundaries for a display, including the minimum and maximum vertical sync frequencies (in Hz, bytes 5 and 6), horizontal sync frequencies (in kHz, bytes 7 and 8), and the maximum supported pixel clock (in units of 10 MHz, byte 9).[5] These values allow graphics sources to generate timings within the display's capabilities, with optional offset flags in byte 4 (bit 5 for vertical, bit 3 for horizontal) extending ranges beyond 255 Hz or kHz for high-performance monitors.[5] When the Generalized Timing Formula (GTF) secondary curve is supported, byte 10 is set to 02h, and bytes 11 through 16 encode the GTF secondary curve parameters: start break frequency in kHz divided by 2 (byte 11), offset constant C multiplied by 2 (byte 12), multiplier M as 16-bit value (bytes 13-14, LSB first), scaling factor K (byte 15), and adjustment constant J multiplied by 2 (byte 16), with byte 17 reserved (00h).[5][17] This secondary curve refines the default GTF by incorporating these parameters for non-linear blanking calculations, particularly useful for CRTs and LCDs requiring adjusted front and back porch margins to optimize image centering and stability across varying resolutions. The GTF formula for horizontal blanking under this curve is given by $ H_{\text{blank}} = \round\left( \frac{A \cdot V_{\text{pixels}} + B \cdot V_{\text{freq}} + C}{P_{\text{clock}} / H_{\text{pixels}}} + D \right) $, where A, B, C, and D derive from the encoded coefficients, and a similar expression applies to vertical blanking; this approach ensures compliant timings by scaling blanking intervals based on vertical dimensions and refresh rates.[17] Support for Coordinated Video Timings (CVT) is indicated by setting byte 10 to 04h within the descriptor, signaling the display's ability to handle timings optimized for flat-panel efficiency with reduced blanking overhead.[5] Bytes 11-17 then detail: version (byte 11=01h), maximum active pixels per line (16-bit little-endian, bytes 12-13), supported aspect ratios (byte 14, bits 7-4: 4:3=0001b, 16:10=0010b, 16:9=0100b, 5:4=1000b; bits 3-0 reserved), preferred vertical refresh rate (byte 15, bits 1-0: 00b=60 Hz, 01b=75 Hz, 10b=85 Hz, 11b=50 Hz; bits 7-2 reserved), bytes 16-17 reserved.[5] This enables sources to select CVT timings with minimal blanking for LCD and digital displays. The core CVT pixel clock formula is $ P_{\text{clock}} = H_{\text{total}} \times V_{\text{total}} \times R_{\text{refresh}} $, which coordinates horizontal and vertical totals to minimize blanking and support modular clock steps of 0.25 MHz, prioritizing bandwidth efficiency for LCD and digital displays.[18]

Color Point and Management Data

In EDID version 1.4, color point data is primarily conveyed through the display chromaticity coordinates block, which specifies the color characteristics of the display's primaries and white point using CIE 1931 chromaticity coordinates.[5] This block occupies bytes 19h through 22h of the main EDID structure, encoding 10-bit binary fractions for the red (Rx, Ry), green (Gx, Gy), blue (Bx, By), and white (Wx, Wy) points, with low-order bits in bytes 19h and 1Ah, and high-order bits in bytes 1Bh through 22h.[5] The values represent fractions of the CIE 1931 (2°) color space, scaled by a factor of 1024 for precision (accurate to approximately ±0.0005), allowing video sources to map content colors accurately to the display's native gamut.[5] The white point defined here serves as the default reference (typically the factory-set value at power-on), often aligned with standard illuminants like D65 for sRGB compliance.[5] A dedicated sRGB support flag in bit 2 of the feature support byte (18h) indicates if the display adheres to the sRGB color space standard (IEC 61966-2-1), requiring the chromaticity coordinates to match sRGB primaries and the D65 white point (approximately x=0.3127, y=0.3290).[5] When this flag is set, sources apply sRGB gamma (approximately 2.2) and color space transformations without additional calibration, ensuring consistent rendering on compatible displays.[5] For displays supporting multiple white points or custom color spaces, the Additional Color Point Descriptor (tag FBh) provides optional extensions in the monitor descriptor blocks (bytes 36h–7Dh).[5] Each 18-byte descriptor begins with the header 00 00 00 FB 00, followed by data for up to two additional white points: byte 5 specifies the index (01h–FFh, with 00h indicating no data), bytes 6–8 encode the white-x coordinate (10 bits, low bits in byte 6), bytes 9–11 encode white-y similarly, and byte 12 provides the associated gamma value (00h–FEh representing (gamma × 100) – 100, e.g., 120h for gamma 2.2; FFh defers to extension blocks).[5] Bytes 13–17 are padding or line feeds (0Ah 20h). With up to three such descriptors available (after allocating blocks for other uses like range limits), this supports defining up to six color points total, including the default, for scenarios like D65 (sRGB/BT.709) or custom primaries in wide-gamut displays.[5] This enables sources to select appropriate white points and gamma for accurate color reproduction, particularly in professional or calibrated environments.[5] The Color Management Data Descriptor (tag F9h) further enhances color handling by providing coefficients for advanced transformations, as defined in the VESA Display Color Management (DCM) Standard Version 1.[5] This optional 18-byte block starts with header 00 00 00 F9 00, byte 5 as version (typically 03h), and bytes 6–17 containing six 16-bit signed polynomial coefficients (LSB first): a3 and a2 for red (bytes 6–9), green (10–13), and blue (14–17).[5] These coefficients form part of a 3x3 color management matrix or polynomial model to convert between the display's native primaries and standard spaces like sRGB or Adobe RGB (1998), accounting for deviations from ideal primaries.[5] For instance, on a wide-gamut display supporting DCI-P3, flags or combined chromaticity data signal the source to apply BT.709-to-DCI-P3 mapping, improving color accuracy in HDR or cinematic content without overdriving the panel.[5] Byte-level flags are not explicitly defined in base EDID 1.4 for specific spaces like DCI-P3, but the structure integrates with extension blocks for such indications.[5]

CVT Timing Support

The CVT 3-byte timing codes descriptor in EDID 1.4 is an 18-byte monitor descriptor identified by tag F8h in bytes 0–4 (00h 00h 00h F8h 00h), followed by version byte 5 set to 01h, allowing up to four 3-byte codes in bytes 6–17 to specify supported Coordinated Video Timings (CVT) modes not covered by established or standard timings.[5] Each 3-byte code encodes the vertical active pixels (11 bits for N = floor((V_active - 1)/2), derived as N = ((byte 7 bits 7-5 << 8) | byte 6), then V_active = 2 * N + 1), aspect ratio (2 bits in byte 7 bits 3–2: 00b for 4:3, 01b for 16:9, 10b for 16:10, 11b for 15:9), preferred vertical refresh rate (2 bits in byte 8 bits 6–5: 00b for 50 Hz, 01b for 60 Hz, 10b for 75 Hz, 11b for 85 Hz), and five flag bits in byte 8 bits 4–0 indicating supported refresh rates and blanking options (e.g., bit 0 for reduced blanking version 1 with ~0.5% Hsync offset, bit 1 for reduced blanking version 2).[5] The horizontal active pixels are then computed as H_active = 8 × round((V_active × aspect_ratio_fraction) / 8), where aspect_ratio_fraction is 4/3, 16/9, 16/10, or 15/9 as appropriate (ensuring multiple of 8).[5] Full timing parameters, including horizontal total, are derived by applying the CVT standard formulas to the decoded parameters, prioritizing reduced blanking where flagged to minimize non-active periods.[19] For reduced blanking (version 1), the horizontal blanking is calculated to achieve an ideal duty cycle near 20% while ensuring minimum sync and porch durations (e.g., horizontal front porch ≥ 1.25% of active, sync width ≥ 8% of total, back porch ≥ 4.8 µs), resulting in H_total = H_active + H_blank.[19] A representative example is the code for 1920×1080 at 60 Hz with reduced blanking: byte 6 = 0x1B, byte 7 = 0x48 (high bits 010b in 7-5 for N=539=0x21B, aspect 01b for 16:9 in 4-3), byte 8 = 0x41 (preferred 60 Hz with bits 6-5=01b, bit 0 set for reduced blanking v1), yielding H_active = 1920, and per CVT 1.1 formulas, H_total = 2200 pixels (H_blank = 280) with pixel clock 148.5 MHz.[5][19] This descriptor enables precise signaling of CVT modes optimized for flat-panel displays, reducing vertical blanking to as low as 460 µs and horizontal blanking variably (e.g., 280 pixels for the above example versus 530 for standard blanking), thereby supporting higher refresh rates on bandwidth-limited links without excessive pixel clock increases.[19] The additional standard timings descriptor, using tag FAh in bytes 0–4 (00h 00h 00h FAh 00h) and version 01h in byte 5, extends the core EDID's eight 2-byte standard timings (bytes 38h–45h) by providing six more 2-byte entries in bytes 6–17 (e.g., bytes 6–7 for timing 9, up to bytes 16–17 for timing 14), each encoding horizontal active ÷ 8 – 31 (6 bits), aspect ratio and refresh – 60 (10 bits).[5] These additional codes allow monitors to declare support for extra resolutions like 1440×900 or 1680×1050 at common rates, using the same compact format as the core block but placed in a detailed timing descriptor slot for flexibility in modern LCD configurations.[5] Together, these features in EDID 1.4 facilitate efficient communication of CVT-based timings, emphasizing minimal blanking to align with LCD characteristics and enable higher performance without compatibility issues from legacy CRT-oriented standards.[5]

Additional Video Timing Codes

The Established Timings III descriptor, introduced in EDID 1.4, serves as a compact mechanism to indicate support for additional VESA Discrete Monitor Timings (DMT) beyond those covered by the base Established Timings I and II fields or standard timing identifiers.[5] This optional monitor descriptor, tagged with F7h, allows displays to signal compatibility with up to 44 predefined video modes in a bit-mapped format, promoting broader interoperability without requiring space-intensive detailed timing blocks.[5] The descriptor occupies an 18-byte block within the monitor descriptors section of the EDID base structure (bytes 108-125 or similar positions). It begins with the standard short descriptor header (bytes 0-2: 00h 00h 00h), followed by the tag byte (byte 3: F7h), a revision byte (byte 4: typically 0Ah), and then 12 bytes of bit flags (bytes 5-16) where each set bit (1) denotes support for a specific VESA DMT mode.[5] The final two bytes (17-18) are reserved and set to 00h. Each bit maps to a unique timing from the VESA DMT standard, covering resolutions from 640x350 to 2560x1600 and refresh rates up to 120 Hz, with most using normal blanking unless specified as reduced blanking (RB).[5] This structure enables efficient encoding of support for over 47 modes across 13 bytes of flag data (bytes 4-16), referencing timings like 720x400@85 Hz (DMT ID 3 variant) and higher-resolution widescreen formats.[5] For instance, the following table illustrates representative bit assignments from the specification's Table 3.36:
ByteBitResolution and Refresh RateDMT Notes
571920×1200 @ 60 Hz (RB)Reduced blanking
561920×1080 @ 60 HzWidescreen
671600×1200 @ 60 HzStandard aspect
651280×1024 @ 75 HzCommon legacy
731440×900 @ 60 HzWidescreen
871360×768 @ 60 HzWidescreen
These modes assume proper image sizing and centering when supported, and the descriptor does not imply range limits or priority ordering—supported modes are evaluated after preferred and detailed timings but before derived modes like GTF or CVT.[5] It complements other timing mechanisms, such as CVT support, by focusing on predefined DMT standards for legacy and standard displays.[5] If the descriptor is unused, a dummy descriptor (tag 10h) should occupy its slot to maintain structure integrity.[5]

CTA Extension Block

CTA-861 Compliance

The CTA-861 standard, originally published as CEA-861 in 2002 by the Consumer Technology Association (CTA) and most recently revised as CTA-861-J in October 2025, defines protocols, requirements, and recommendations for transporting uncompressed video, audio, and auxiliary data over high-speed digital interfaces such as HDMI, DVI, and DisplayPort in consumer electronics devices.[20][21] This standard builds upon the base EDID structure by mandating a dedicated CTA extension block to enable sinks (e.g., displays and TVs) to report their capabilities, ensuring interoperability between sources and sinks in HDMI ecosystems.[22] The primary purpose of CTA-861 is to extend the core EDID for consumer electronics applications, incorporating HDMI-specific features such as Audio Return Channel (ARC) for bidirectional audio transmission, High-bandwidth Digital Content Protection (HDCP) for secure content playback, and support for 3D video formats.[23] This extension facilitates the negotiation of advanced multimedia capabilities, allowing devices to optimize signal transmission for high-definition content without custom signaling beyond standard video blanking intervals.[24] In the EDID structure, the CTA extension block is designated by extension tag 0x02, with the revision version encoded in byte 1 as 0x03, used in CTA-861-G and subsequent revisions such as H, I, and J.[22] Following the two-byte header (tag and revision) and the offset byte, the block contains data blocks starting from the specified offset (typically byte 4), detailing supported timings, audio formats, and vendor-specific information, ending with a checksum byte.[25] Compliance with CTA-861 is required for all HDMI sinks, which must incorporate the CTA extension block in their EDID to declare support for formats like 4K UHD resolutions, HDR10 metadata, and Dolby Vision dynamic HDR.[26] HDMI sources rely on parsing this block to select compatible modes, ensuring reliable playback of protected content. As of 2025, the standard accommodates video up to 8K at 60 Hz and Variable Refresh Rate (VRR) for smoother motion handling, though EDID's static nature limits it to advertising fixed capabilities rather than dynamic adjustments.[27][28]

Extension Block Format

The CTA Extension Block forms a 128-byte structure within the Enhanced EDID (E-EDID) framework, designed to convey detailed audio and video capabilities of a display sink for uncompressed high-speed digital interfaces as specified in CTA-861.[29] This block's header occupies the first three bytes: byte 0 is fixed at 02h to identify it as the CTA extension tag, byte 1 is set to 03h to indicate revision 3 of the CTA format (used since CTA-861-D and in all later versions), and byte 2 specifies the offset to the start of the first data block (typically 04h, making bytes 3 unused and set to 00h).[29] Bytes from the offset to 126 contain the data blocks, with byte 127 as the checksum ensuring the sum of all 128 bytes is 00h modulo 256.[29] From the offset, the block contains a sequence of variable-length data blocks structured in a tag-length-value (TLV) format, where each block begins with a tag byte (indicating type, 0-7 for short or 7 with extended tag for 0x00-0x1F) followed by a length byte (0-31) and the payload.[29] These data blocks collectively describe supported formats and must fit within the available space up to byte 126.[29] Data blocks vary in length: short descriptors are compact, typically 1 to 15 bytes (e.g., for listing video identification codes or audio formats), while some extended descriptors can be longer (e.g., for detailed parameters).[29] For instance, a short video data block might enumerate standard timings via 1-byte codes, whereas vendor-specific blocks provide details for custom modes.[29] Parsing involves the source device sequentially reading blocks from the offset until the end of the available space (byte 126), identifying types via tags and validating against the standard, with the extension accommodating multiple blocks to balance extensibility and efficiency.[29] This layout aligns with CTA-861 requirements for robust capability exchange in digital video systems.[29]

Video and Audio Data Blocks

The Video Data Blocks within the CTA extension block of EDID describe the display's supported video formats, primarily through Short Video Descriptors (SVDs) that reference standardized Video Identification Codes (VICs).[5] These blocks use tag code 0x02 and consist of a header byte specifying the tag and length, followed by one or more 1-byte SVDs, where bit 7 indicates the native format (1 for native, 0 otherwise) and bits 0–6 encode the VIC value ranging from 1 to 127.[30] VICs map to predefined timings in the CTA-861 standard, such as VIC 1 for 640×480 at 60 Hz (4:3 aspect ratio) or VIC 16 for 1920×1080p at 60 Hz (16:9). A representative example is VIC 95, which specifies 3840×2160p at 60 Hz, commonly used for 4K UHD content. Additional video features beyond basic SVDs, such as 3D support (e.g., frame packing or side-by-side formats), are advertised in the HDMI Vendor-Specific Data Block (VSDB). Static HDR metadata, including the Electro-Optical Transfer Function (EOTF), desired maximum luminance, and colorimetry support like BT.2020, is conveyed in the HDR Static Metadata Data Block (tag code 7, extended tag 0x06) for static metadata types 1 (traditional HDR) or 2 (SMPTE ST 2084).[31] The CTA extension can accommodate multiple Video Data Blocks (up to the space limit), allowing for comprehensive coverage of supported resolutions and features.[5] Audio Data Blocks, tagged with code 0x01, detail the sink's audio capabilities using Short Audio Descriptors (SADs), each spanning 3 bytes to specify format, sampling frequencies, and channel or bit-depth information.[30] The first byte encodes the audio format code (e.g., 1 for LPCM, 2 for AC-3/Dolby Digital), the second byte uses bit flags for supported sampling rates (32–192 kHz, such as 48 kHz via bit 0), and the third byte indicates maximum channels (up to 8, e.g., 2 for stereo or 7 for 7.1 surround) or bit depths for LPCM (16–24 bits). For instance, an LPCM SAD might specify format code 1, frequencies including 32/44.1/48 kHz (bitmask 0x07), and 2 channels with 16/20/24-bit support (byte 3 = 0x07).[30] Up to 15 audio data blocks are permitted in the CTA extension, facilitating declaration of multiple formats like DTS (code 8) or MPEG-H 3D Audio in extended versions. The presence of Audio Data Blocks in the CTA extension signals basic audio support over the interface, while HDMI Audio Return Channel (ARC) capability is indicated through flags in the extension's vendor-specific blocks, enabling audio transmission from the display back to the source without additional cabling. These blocks follow a sequential order in the data block collection, prioritizing native or preferred formats for optimal source-display negotiation.[5]
Representative Video Identification Codes (VICs)Resolution and Refresh RateAspect RatioNotes
1640×480 @ 60 Hz4:3Standard VGA timing
161920×1080p @ 60 Hz16:9Full HD progressive
953840×2160p @ 60 Hz16:94K UHD, pixel aspect 1:1
Representative Audio Format CodesFormatMax ChannelsSampling Frequencies (kHz)Bit Depths (LPCM)
1LPCM832–19216–24
2AC-3632–48N/A

Vendor-Specific and Configuration Blocks

The Vendor-Specific Data Block (VSDB), identified by tag code 0x03 in the CTA Extension Block, allows manufacturers to convey proprietary information tailored to their devices, typically spanning 3 to 9 bytes including a header.[30] It begins with a 3-byte IEEE Organizationally Unique Identifier (OUI) stored in least significant byte first order, followed by vendor-defined payload; for example, the HDMI Forum uses OUI 0xD85DC4 to signal HDMI-specific capabilities.[30][32] The subsequent byte indicates the HDMI version (e.g., 0x01 for HDMI 1.0, up to 0x05 for HDMI 1.4), while additional fields cover video and audio latency for progressive and interlaced formats, 3D transmission support, and quantization range (QC) settings for limited or full RGB/YUV color depth.[30] These elements enable sources to configure HDMI features such as deep color support at 10-bit or 12-bit per channel, optimizing video quality and synchronization.[30] A notable extension of the VSDB appears in 2025 implementations for head-mounted displays (HMDs), utilizing Microsoft's OUI 0xCA125C to denote specialized VR/AR capabilities.[15] The version byte specifies HMD type: 0x01 for Windows Mixed Reality HMDs compatible with Windows 10 version 1703 and later, or 0x02 for HMDs supporting non-Microsoft compositors from Windows 10 version 1809 onward.[15] This variant integrates with CTA-861 protocols to facilitate plug-and-play detection of HMD-specific features, though advanced attributes like eye-tracking and foveated rendering are primarily detailed in complementary standards such as DisplayID v2.0.[15][6] The Speaker Allocation Data Block, tagged 0x04, consists of 3 bytes and uses a bitmap to declare supported multi-channel audio configurations, enabling sources to map audio channels accurately to the sink's speakers.[30] The bitmap spans bits 0 through 10 across the three bytes, where bit 0 represents front left/right (FL/FR) channels, bit 1 low-frequency effects (LFE), bit 2 front center (FC), bit 3 rear left/right (RL/RR), bit 4 rear center (RC), bit 5 front height left/right (FLH/FRH), and higher bits for additional positions like side surround or top channels, supporting layouts up to 7.1 surround sound.[30] For instance, a value of 0x13 (binary 00010011) indicates support for FL/FR, LFE, FC, and RL/RR.[30] This block ensures proper audio rendering without distortion, particularly in home theater systems.[30] The Room Configuration Data Block, with Data Block Tag Code 7 and Extended Tag Code 0x13, and less commonly implemented, extends speaker allocation by providing details on room-specific audio synchronization and layout, typically for multi-room or advanced acoustic environments.[33] It follows the standard CTA data block format with a variable length payload (often n bytes after the tag and length fields) to describe extended speaker positions relative to room geometry, such as back left/right or height channels beyond basic 7.1 setups.[33] This rare block aids in synchronizing audio across distributed systems, improving immersion in scenarios like whole-home audio distribution.[34] Together, these configuration blocks in the CTA extension allow sources to dynamically adjust audio and video parameters, enhancing compatibility in HDMI and similar digital interfaces.[30]

Limitations and Compatibility Issues

Technical Constraints

The EDID format is fundamentally limited by its fixed 128-byte block size for the base structure (Block 0), which restricts the conveyance of detailed display capabilities to essential elements such as manufacturer identification, basic timings, and a limited set of supported modes. This base block allocates space for up to four 18-byte detailed timing descriptors, alongside established timings (8 bytes), standard timings (16 bytes), and monitor descriptors (up to four 18-byte blocks), leaving minimal room for expansion without extensions. With a single 128-byte extension block—the most common configuration—the total capacity extends to 256 bytes, which is inadequate for encoding the extensive timing information required for ultra-high-resolution displays, such as 8K (7680×4320) modes, as the detailed timing format caps horizontal and vertical addressable pixels at 4095 due to 12-bit field encoding.[5][5][5] EDID data is static by design, serving as a one-time readout of the display's fixed capabilities via the DDC interface, without provisions for real-time updates to accommodate dynamic features like variable refresh rate (VRR) or adaptive synchronization technologies such as FreeSync. Support for such features, when present, is declared statically in extension blocks (e.g., via flag bits in CTA extensions), but cannot adjust during operation; any changes to supported modes require a physical reconnection or power cycle to trigger a re-read of the EDID. This rigidity stems from the format's reliance on non-volatile storage like EEPROM in the display, pre-programmed at manufacturing.[5][5][5] The checksum mechanism adds further constraint, with each 128-byte block concluding in a single byte that must sum the preceding 127 bytes (plus the header checksum) to zero modulo 256; even trivial modifications to the data invalidate the block entirely, as there is no error detection beyond this simple parity check or forward error correction to mitigate transmission noise over the DDC. This design prioritizes integrity verification but hampers post-manufacture customization or debugging without specialized tools to recalculate checksums.[5][5] EDID transmission occurs over the Display Data Channel (DDC), an I²C-based protocol limited to a standard-mode clock frequency of 100 kHz, which constrains data read speeds to approximately 100 kbit/s after accounting for protocol overhead, leading to delays of several milliseconds per block—cumulatively significant in multi-monitor configurations requiring sequential polling of multiple devices. While enhanced DDC (E-DDC) allows access to up to 32 KB via segment addressing, the underlying I²C bandwidth remains a bottleneck for rapid initialization in complex setups.[35][9] Backward compatibility is enforced through a versioned structure (e.g., EDID 1.4), where unrecognized fields or entire extension blocks are ignored by legacy sources, causing them to default to conservative low-resolution modes (e.g., 640×480 or VGA equivalents) derived solely from the base block's established timings. This ensures interoperability with older hardware but perpetuates suboptimal performance on modern displays when paired with pre-EDID 1.3 sources. The CTA-861 extension block partially addresses size constraints by introducing compact short descriptors for additional video timings, enabling support for more modes within the 128-byte limit.[5][5][5]

Common Implementation Problems

One prevalent issue in EDID implementation arises from corruption in the display's EEPROM, where faulty storage leads to incomplete or invalid data transmission, resulting in symptoms such as "no signal" messages or persistent black screens during handshake with the source device.[36] This corruption can occur due to manufacturing defects, power surges, or repeated connection cycles that degrade the non-volatile memory.[37] To mitigate these problems, users often employ software tools like the Custom Resolution Utility (CRU), which creates registry-based EDID overrides in Windows without altering the hardware, allowing the system to ignore the corrupted data and apply a custom profile.[38] In remote or headless configurations lacking a directly connected monitor, the PC may fail to read EDID data, defaulting to low resolutions such as 640×480. Physically connecting the monitor via HDMI or DisplayPort enables the system to query the display's EDID over the interface, thereby recognizing the native resolution options, including 3840×2160 for 4K monitors, irrespective of prior remote access settings.[39] Another common challenge involves mismatches when using HDMI extenders or switches, including KVM switches that allow multiple computers to share a single monitor, keyboard, and mouse. These devices frequently feature built-in EDID emulators that poorly replicate the display's capabilities, causing the source to default to lower resolutions such as dropping from 4K to 1080p to ensure compatibility. In KVM switches particularly, poor EDID handling can lead to "no signal" messages, black screens, or signal loss when switching between computers, as the source fails to receive consistent EDID data due to temporary interruptions in the DDC connection.[36][40][41] These emulators may fail to accurately convey supported timings or audio formats, leading to handshake failures and suboptimal video output in multi-device setups like home theaters or conference rooms. Such problems are mitigated by using KVM switches with built-in EDID emulation, which maintains persistent EDID data across switches to keep the display appearing "online" to all connected computers, or by adding external EDID emulators for the same effect. Basic troubleshooting steps include using high-quality cables and power cycling devices.[40][41] In multi-monitor configurations, particularly with DisplayPort daisy-chaining, a single faulty EDID in the chain can propagate errors, blocking signal passthrough and causing downstream displays to lose detection or revert to basic modes. This occurs because the Multi-Stream Transport (MST) protocol relies on sequential EDID reads, and an invalid block from one monitor disrupts the entire topology, often requiring physical reconfiguration or individual testing to isolate the issue.[42][43] Vendor non-compliance exacerbates these problems, as some displays ship with incomplete Consumer Technology Association (CTA) extension blocks that omit critical data for features like High Dynamic Range (HDR), preventing sources from enabling enhanced color and brightness capabilities despite hardware support. Such omissions stem from inconsistent adherence to CTA-861 standards during manufacturing, resulting in displays that underperform in HDR workflows without manual intervention.[38][44] Effective solutions include hardware EDID programmers, such as the ATEN VC080 emulator, which capture and rewrite valid EDID data directly to the display's EEPROM for permanent fixes in professional installations.[45] Additionally, Windows users can deploy manufacturer-provided or custom INF files to override EDID at the driver level, injecting corrected blocks for resolutions, timings, and features like HDR without hardware access. These approaches address deployment errors stemming from format constraints, ensuring reliable compatibility across diverse setups.[46][36]

Successor and Extended Standards

DisplayID as Replacement

DisplayID, developed by the Video Electronics Standards Association (VESA), emerged in 2009 as a modular successor to EDID, designed to overcome the constraints of EDID's fixed 128-byte structure by providing a more adaptable framework for describing display capabilities in an era of rapidly evolving technologies.[6] This standard utilizes variable-length data blocks, enabling payloads up to several kilobytes—far exceeding EDID's limitations—to accommodate complex features such as tiled display configurations, resolutions beyond 4K (including support for 16K and higher with appropriate compression), and dynamic audio/video parameters.[16][47] The core structure begins with an 18-byte header that identifies the overall format and length, followed by tiled sequences of self-contained data blocks—such as tile maps for multi-panel setups, range limits for signal capabilities, and detailed timing descriptors—which collectively define the display's physical, performance, and interface attributes.[2][16] This modular approach extends to modern interfaces like embedded DisplayPort (eDP) for internal laptop connections and USB4 for versatile docking and peripheral integration.[6] Compared to EDID, DisplayID's extensible Tag-Length-Value (TLV)-inspired block format removes the rigid size constraints, allowing seamless addition of new descriptors without breaking compatibility.[6][3] Adoption has grown steadily, with DisplayID becoming a key component in contemporary standards; it is utilized in DisplayPort 2.1, released in 2022, which leverages it to enable advanced modes such as 8K at 120 Hz with backward compatibility through EDID fallback for legacy systems. Windows 11 supports DisplayID 2.0 as an EDID extension for high dynamic range (HDR) properties as of 2021.[48][6][49] A 2013 update introduced explicit tiled display support for multi-processor video walls and stereo 3D timings, while the 2017 version 2.0 refresh added provisions for high dynamic range (HDR), adaptive synchronization, and augmented/virtual reality (AR/VR) requirements, ensuring robust plug-and-play operation across PC monitors, consumer televisions, and professional displays.[16][6]

Specialized Extensions (e.g., Head-Mounted Displays)

The Microsoft EDID extension for head-mounted displays (HMDs), introduced with Windows 10 version 1703 in 2017, utilizes a Vendor Specific Data Block (VSDB) within the CTA-861 extension to enable specialized identification and configuration for Windows Mixed Reality devices.[15] This block begins with a tag code of 0x03 and a length of 0x15, followed by the Microsoft-assigned IEEE Organizationally Unique Identifier (OUI) encoded as bytes 0x5C, 0x12, 0xCA.[15] The version byte specifies the display type, with value 0x01 indicating an HMD compatible with Windows 10 version 1703 and later, allowing the operating system to detect the device and apply VR-specific drivers that exclude it from the desktop composition for exclusive full-screen access.[15] Subsequent flags include a desktop usage bit (set to 0x00 to prevent inclusion in multi-monitor setups) and a non-Microsoft compositor bit (set to 0x00 for Windows-only use), along with a 5-bit use case field (e.g., 0x07 for VR headsets or 0x08 for AR), culminating in a 16-byte container ID for unique device identification.[15] This extension supports niche applications by designating VR or AR use cases, permitting Windows to optimize for these without relying on standard desktop drivers.[15] Beyond Microsoft's implementation, VESA's DisplayID standard provides extensions for tiled VR configurations, where multiple panels form a wider effective display, though traditional EDID remains in use for legacy VR headsets such as the Oculus Rift to report custom timings like 2160x1200 at 90 Hz.[6][50] A key challenge with these EDID-based extensions is their reliance on static data read once at connection, limiting parameters to fixed values that cannot adapt dynamically during use; for real-time adjustments, such as variable configurations in advanced VR scenarios, DisplayPort 2.0's Sideband Messaging protocol is employed instead to transmit updates over the auxiliary channel.[51]

References

  1. Understanding EDID - Extended Display Identification Data
  2. EDID and DisplayID | Basic Input/Output
  3. Understanding EDID - Extended Display Identification Data | Extron
  4. EDID Management - RGB Spectrum
  5. [PDF] VESA E-EDID Standard Release A2 (EDID 1.4) - Glenwing
  6. VESA Rolls Out DisplayID Version 2.0 Standard to Optimize Plug ...
  7. EDID: Extended Display Identification Data - Documents - Video
  8. [PDF] VESA E-EDID Standard Release A1 (EDID 1.3) - Glenwing
  9. [PDF] VESA Enhanced Display Data Channel (EDDC) Standard Version 1.2
  10. [PDF] DisplayPort Technical Overview - VESA
  11. [PDF] DisplayPort TM Alternate Mode on USB-C - VESA
  12. [PDF] Understanding EDID - Extended Display Identification Data - Extron
  13. EDID ( Extended display identification data ) - HDFURY
  14. [PDF] Display Technology, VESA and EDID - X.Org
  15. EDID Extension for Head-Mounted and Specialized Monitors
  16. VESA Refreshes DisplayID Standard to Support Higher Resolutions ...
  17. [PDF] VESA Generalized Timing Formula Standard Version: 1.1 - Glenwing
  18. [PDF] VESA Coordinated Video Timings (CVT) Standard, Version 1.2
  19. [PDF] VESA® - Parallax Forums
  20. https://store.accuristech.com/standards/cta-861-h
  21. [PDF] ETSI TS 103 433-3 V1.2.1 (2021-08)
  22. Wayback Machine
  23. A DTV Profile for Uncompressed High Speed Digital Interfaces
  24. CTA-861 - Consumer Technology Association
  25. src/backends/edid-parse.c - GitLab - GNOME
  26. [PDF] A/341, "Video - HEVC" - ATSC.org
  27. [PDF] HDMI SIGNAL MODULE MODEL A223814
  28. HDMI Signal Module Model A223814 - Chroma ATE Inc.
  29. https://shop.cta.tech/products/cta-861
  30. [PDF] CEA Standard
  31. HDR Static Metadata Extensions - Consumer Technology Association
  32. Device and method for transmitting and receiving data using hdmi
  33. ANSI CTA-861-I Errata Updated | PDF | Video - Scribd
  34. CTA 861 5 Final | PDF | Digital Technology | Computer Data - Scribd
  35. [PDF] VESA DDC/CI Standard, Version 1.1 - Glenwing
  36. https://www.sct.com.tw/articles/the-quickest-way-to-solve-your-edid-issues
  37. RepairEDID - Debian Wiki
  38. Custom Resolution Utility (CRU) - Monitor Tests
  39. Using an INF File to Override EDIDs - Windows drivers
  40. No Video on DisplayPort to HDMI Daisy Chained Display from ... - Dell
  41. DisplayPort 1.2 Daisy Chain Third Monitor Not Working - Super User
  42. Strange HDR Problem - General Support - LibreELEC Forum
  43. 4K HDMI EDID Emulator with Programmer - VC080, ATEN Video ...
  44. VESA Publishes DisplayPort™ 2.0 Video Standard Enabling ...
  45. VESA Releases DisplayPort 2.1 Specification
  46. nvidia - Register a device as Direct Mode capable? (VR Headset ...
  47. [PDF] DisplayPort - VESA
  48. Why is remote desktop very slow when host monitor is off unless HDMI cable is used?
  49. EDID-Emulation Explanation
  50. Why Video Behaves Differently with KVM Switches
User Avatar
No comments yet.