EDID-DECODE(1)

📦

version 1.32.0 · 4 versions

1.32.0 · alpine 3.24, arch rolling, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable (latest)
1.30.1 · fedora 43, opensuse-leap 16.0
0.1~git20201230.95d81c9 · ubuntu jammy
0.1~git20220315.cb74358c2896 · debian bookworm, debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

, in alpine 3.24, arch rolling, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

💖 EDID-DECODE — the manual page, but make it make sense 💖

okay bestie, gather round, because this is edid-decode(1) from the User Commands section and it is genuinely one of the most useful little gremlins on your system. no cap.

✨ NAME ✨

edid-decode — decodes EDID data and turns it into something a human can actually read. you know, instead of a wall of hex that makes your eyes glaze over 🫶

🌸 SYNOPSIS 🌸

edid-decode <options> [in [out]]

🦋 DESCRIPTION 🦋

So edid-decode takes EDID monitor description data and decodes it into a human-readable format. that's the whole vibe. 💅

Here's how the in/out situation works, and yes it's giving very flexible:

If [in] isn't given, or if [in] is -, then the EDID gets read from standard input. yes, it will just sit there and wait for you to pipe things into it, iconic behaviour honestly.
If [out] is given, then whatever EDID was read from [in] gets written to [out] — or to standard output if [out] is -. By default the output is written as a hex dump when writing to standard output, or a raw EDID if written to a file.
⚠️ Important one: if [out] is given, then edid-decode only does the conversion. It skips the decoding step entirely. so don't be out here expecting a pretty decode when you asked for a conversion, that's on you bestie 😭

Input files can be raw binaries or ASCII text. When it's ASCII, it gets scanned for hex dumps, and there are heuristics baked in to hunt down hexdumps in:

edid-decode(1) output — as long as the initial hex dump was included
xrandr(1) property output
Xorg(1) log file formats

otherwise the data is just treated as a raw hexdump. and if you're wondering where to even find EDID blocks for your connected monitors — they live in /sys/class/drm/*/edid on modern Linux systems with kernel modesetting support. go look, it's right there. 🎀

⭐ the timing format (this part is important) ⭐

All timings are shown in a short format, for example:

    VIC  16:  1920x1080   60.000 Hz  16:9    67.500 kHz 148.500 MHz (native)
    VIC   5:  1920x1080i  60.000 Hz  16:9    33.750 kHz  74.250 MHz
    VIC  39:  1920x1080i  50.000 Hz  16:9    31.250 kHz  72.000 MHz

Each format starts with a timings type prefix, then the resolution, then an optional interlaced indicator (i), then the frame rate (which is the field rate for interlaced formats), then the picture aspect ratio, then the horizontal frequency, then the pixelclock frequency — and optionally some extra flags tucked between parentheses. 💅

⚠️ careful with the interlaced ones: for interlaced formats the frame height is given, NOT the field height. So each field in a 1920x1080i format has 540 lines. do not come for me about this, that's just how it is.

Detailed timings get another 2-3 lines of data on top of that:

    VIC  16:  1920x1080   60.000 Hz  16:9    67.500 kHz 148.500 MHz (native)
                   Hfront   88 Hsync  44 Hback 148 Hpol P
                   Vfront    4 Vsync   5 Vback  36 Vpol P
    VIC   5:  1920x1080i  60.000 Hz  16:9    33.750 kHz  74.250 MHz
                   Hfront   88 Hsync  44 Hback 148 Hpol P
                   Vfront    2 Vsync   5 Vback  15 Vpol P Vfront +0.5 Odd Field
                   Vfront    2 Vsync   5 Vback  15 Vpol P Vback  +0.5 Even Field
    VIC  39:  1920x1080i  50.000 Hz  16:9    31.250 kHz  72.000 MHz
                   Hfront   32 Hsync 168 Hback 184 Hpol P
                   Vfront   23 Vsync   5 Vback  57 Vpol N Both Fields

These describe the horizontal and vertical front porch, sync, backporch and sync polarity values. 🧚

For interlaced formats there are two lines for the vertical information:

one for the Odd Field (aka Field 1)
one for the Even Field (aka Field 2)

The vertical front porch of the Odd Field is actually 2.5 — hence the Vfront +0.5 at the end of the line — and the back porch of the Even Field is actually 15.5 — hence the Vback +0.5 at the end of the line. sneaky little halves, obsessed. 🍓

There's also a special VIC 39 interlaced format where both fields have the same vertical timings, and in that case it's marked with Both Fields.

🌈 the timing types you might see 🌈

DMT # — Discrete Monitor Timing (see DMT 1.3 standard). The number is the DMT ID in hexadecimal.
CVT — Coordinated Video Timings (formula-based, see CVT 1.2 standard).
GTF — Generalized Timing Formula (formula-based, see GTF 1.1 standard).
IBM — Old IBM Timings.
Apple — Old Apple Timings.
VIC # — Video Identification Code (see CTA-861 standard). The number is the actual VIC code.
HDMI VIC # — HDMI-specific Video Identification Code (see HDMI 2.1 standard). The number is the actual HDMI VIC code.
DTD # — Detailed Timings Descriptor (see EDID standard). Also used for DisplayID Video Timing Modes Types I, II, VI, VII, VIII and X. The number denotes that this is the Nth DTD in the Base Block and CTA Extension Blocks.
VTDB # — 20-byte DTD or 6- or 7-byte CVT descriptor in a CTA Extension Block. The number denotes that this is the Nth such timing in the CTA Extension Blocks.
RID #@# — A CTA-861.6 Video Format Descriptor with the given Resolution ID (first number) at the given framerate (second number).

💅 long vs short, pick your fighter 💅

By default, DTDs are shown in the long format while everything else is just shown in the short format.

With the option --short-timings, all timings are shown in short format only.
With the option --long-timings, all timings are shown in long format.

And if you want alternate formats for long timings, you can pick them via the --xmodeline or --fbmode options. yes ma'am, options within options, we love a layered situation. ✨

👑 STANDARDS 👑

The following EDID standards are supported by edid-decode:

EDID 1.3 — VESA Enhanced Extended Display Identication Data Standard, Release A, Revision 1
EDID 1.4 — VESA Enhanced Extended Display Identication Data Standard, Release A, Revision 2
DisplayID 1.3 — VESA Display Identification Data (DisplayID) Standard, Version 1.3
DisplayID 2.1a — VESA DisplayID Standard, Version 2.1a
DI-EXT — VESA Display Information Extension Block Standard, Release A
LS-EXT — VESA Enhanced EDID Localized String Extension Standard, Release A
VTB-EXT — VESA Video Timing Block Extension Data Standard, Release A
DTCDB — VESA Display Transfer Characteristics Data Block Standard, Version 1.0
DDDB — VESA Display Device Data Block (DDDB) Standard, Version 1
HDMI 1.4b — High-Definition Multimedia Interface, Version 1.4b
HDMI 2.1b — High-Definition Multimedia Interface, Version 2.1b
HDCP 1.4 — High-bandwidth Digital Content Protection System, Revision 1.4
HDCP 2.3 — High-bandwidth Digital Content Protection System, Mapping HDCP to HDMI, Revision 2.3
CTA-861-I — A DTV Profile for Uncompressed High Speed Digital Interfaces
CTA-861.7 — Improvements to CTA-861-I
SPWG Notebook Panel Specification, Version 3.5
EPI Embedded Panel Interface, Revision 1.0
Microsoft EDID extension for head-mounted and specialized monitors, Version 3

The following related standards are also used by edid-decode:

DMT 1.3 — VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT), Version 1.0, Rev. 13
CVT 2.1 — VESA Coordinated Video Timings (CVT) Standard, Version 2.1
CVT 1.2 — VESA Coordinated Video Timings (CVT) Standard, Version 1.2
CVT 1.2 — VESA CVT v1.2 Errata E2
GTF 1.1 — VESA Generalized Timing Formula Standard, Version: 1.1
HDA 1.0a — High Definition Audio Specification, Version 1.0a

okay and that's just part one bestie, we are SO not done yet, keep scrolling 💖

-h, --help — prints the help message. that's the whole assignment, bestie 🫶
-o, --output-format <fmt> — if [out] is specified, then write the EDID in format <fmt>. and <fmt> can be one of these iconic little guys:
- hex — hex numbers in ascii text (this is the default for stdout)
- raw — binary data (this is the default unless you're writing to stdout)
- carray — c-program struct
- xml — XML data
-c, --check — check if the EDID conforms to the standards. warnings and failures get reported at the end, no cap. ✨
-C, --check-inline — same energy, check if the EDID conforms to the standards, except this time warnings and failures are reported as they happen. live commentary, periodt 💅
-n, --native-resolution — report the native resolution at the end. heads up tho: you might get multiple native resolution reports, and it depends on what the Source actually parses — only Block 0 (that's your DVI outputs vibe), or Block 0 and the CTA-861 Extension Blocks (hi HDMI), or just the DisplayID Extension Blocks (very DisplayPort of them). if every block has the same native resolution, then it only reports that one resolution. and for the older displays out there, you can get two separate native resolutions: progressive and interlaced 😌
-p, --preferred-timings — report the preferred timings at the end. again, could be multiple preferred timing reports depending on whether the Source parses only Block 0 (e.g. DVI outputs), or Block 0 and the CTA-861 Extension Blocks (HDMI), or Block 0 and the DisplayID Extension Blocks (typical for DisplayPort) 🦋
-I, --infoframe <file> — parse the given InfoFrame file. pass '-' as the filename and it reads data from stdin instead. you can use this option multiple times to parse multiple InfoFrames, go off 👑 and if you also hand it the EDID of the display these InfoFrames are being transmitted to, then the conformity checks will take that EDID into account.

here's the tea on the format: if the first byte in the InfoFrame is 0x80 or higher, then it's assumed to be an InfoFrame that starts with the HDMI header and has a checksum, as per the HDMI Specification. otherwise it's assumed to be a regular CTA-861 InfoFrame without a checksum.

Note: this is still work-in-progress, specifically for the AVI and HDMI InfoFrames. 🙈

-E, --eld <file> — parse the given EDID-Like Data (ELD) file. this one can be used multiple times too, for multiple ELD files. read data from stdin if '-' was passed as a filename. and if the EDID of the display to which these ELD files are generated is also given, then the conformity checks will take that EDID into account 💖

on Linux systems you can pull ELD out with the amixer command — just copy all the hex after the 'values=':

$ amixer -c 0 controls | grep ELD
numid=6,iface=PCM,name='ELD',device=3
numid=12,iface=PCM,name='ELD',device=7
numid=18,iface=PCM,name='ELD',device=8
numid=24,iface=PCM,name='ELD',device=9
$ amixer -c 0 cget iface=PCM,name=ELD,device=3
numid=6,iface=PCM,name='ELD',device=3
  ; type=BYTES,access=r--v----,values=95
  :
values=0x10,0x00,0x08,0x00,0x6d,0x10,0x00,0x01,0x00,0x02,0x00,0x00,0x00,0x00,
    0x00,0x00,0x30,0xae,0xf1,0x61,0x4c,0x45,0x4e,0x20,0x54,0x33,0x32,0x68,0x2d,0x32,
    0x30,0x0a,0x20,0x09,0x7f,0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

--diagonal <inches> — specify the diagonal of the display in inches. this turns on extra checks for the image size, checking if it lines up with that diagonal. and yes, this assumes square pixels 🌸
-P, --physical-address — just report the HDMI Source Physical Address and literally nothing else. it reports f.f.f.f if the EDID could not be parsed, or if there was no CTA-861 Vendor-Specific Data Block with OUI 00-0C-03. otherwise it reports the Source Physical Address as provided in that Data Block. this is the perfect little input for HDMI CEC utilities like the linux cec-ctl(1) utility 🔥
-S, --short-timings — report all video timings in a short format. concise queen 👑
-L, --long-timings — report all video timings in a long format. verbose queen 💅
-N, --ntsc — report the video timings with values suitable for NTSC-based video. like, it'll show refresh rates of 29.97 Hz instead of 30 Hz. this only happens for timings with refresh rates that are a multiple of 6, fyi 🌈
-X, --xmodeline — report all long video timings in the ModeLine format as defined in xorg.conf(5). that ModeLine can go straight into your xorg.conf file, or you can pass it to xrandr(1) with the xrandr --newmode option. slay ✨
-F, --fbmode — report all long video timings in the video mode format as defined in fb.modes(5) 🎀
-V, --v4l2-timings — report all long video timings in the video mode format as defined in the linux header v4l2-dv-timings.h, for use with the V4L2 VIDIOC_S_DV_TIMINGS ioctl 🦋
-s, --skip-hex-dump — skip the initial hex dump of the EDID. bye felicia 👋
-H, --only-hex-dump — only show the hex dump of the EDID, then exit. short and sweet 🍓
--skip-sha — don't show the SHA hash. normally edid-decode shows the SHA, i.e. the hash of the git commit used to compile edid-decode. this uniquely identifies the version of edid-decode that's used to generate the warnings and failures. but plot twist: it'll also change the output of edid-decode for every new commit in the git repository, even if nothing else changed in the edid-decode output 😭 use this option to avoid including the SHA in the edid-decode output.
-u, --utf8 — convert embedded EDID strings to UTF-8, using Code Page 437 for the base block and ISO 8859-1 for the DisplayID block 🌸
--hide-serial-numbers — hide any serial numbers in the human readable output by '...'. ngl they're still super easily extracted from the EDID hex dump at the start, so this is more of a vibe thing than a security thing 💀
--replace-unique-ids — replaces any unique IDs in the EDID by fixed values. serial numbers get replaced by '123456', Container IDs by all zeroes, and the 'Made in' date by the year 2000. this will also update any checksums in the EDID and update the EDID hex dump at the start of the output. but heads up bestie: since this updates checksums, any checksum errors present in the original EDID will no longer be detected. gone, reduced to atoms 🙈

where do these live? serial numbers can appear in the Base Block, CTA-861 Extension Blocks, DisplayID Extension Blocks and Localized String Extension Blocks. Container IDs can appear in the DisplayID and CTA-861 Extension Blocks.

and the 'Made in' date appears in the Base Block.

--version — show the SHA hash and the last commit date ⭐

🔌 I2C/DDC OPTIONS 🔌

okay so these next ones read the DDC bus directly, provided the DDC bus is exposed by linux to /dev/i2c-X as an i2c adapter device. yes we're going straight to the hardware, main character energy 🔥

this can be used to read the EDID and HDCP information directly from the sink and parse it. no middleman, no cap 💜

-a, --i2c-adapter <dev> — use the <dev> device to access the DDC lines. if <dev> starts with a digit, then /dev/i2c-<dev> is used ✨
--i2c-edid — read and parse the EDID from the i2c adapter 📖
--i2c-hdcp — read and parse the HDCP data from the i2c adapter 🔐
--i2c-hdcp-ri <t> — every <t> seconds, read and report the HDCP Ri value from the i2c adapter. like a lil heartbeat monitor for your HDCP 🫶
**--i2c-test-reliability [duration=<secs>][,sleep=<msecs>]** — read the EDID continuously for <secs>seconds (default is0, meaning forever 😭), with a sleep of <msecs>milliseconds (default value is50 ms`) in between each read. report a FAIL if there are mismatches between EDIDs. this tests the i2c communication towards the display. stress test, but make it ✨fashion✨

✨ TIMING OPTIONS ✨

Okay bestie, this whole section is the timing calculator era 💅 These options either report timings for DMT, VIC and HDMI VIC codes, or they do the math and calculate timings for CVT or GTF formats based on whatever parameters you hand them. Heads up though: the EDID will not be shown when you use these — which is lowkey sad but it is what it is 😌 The one exception vibe is that it can still be used together with the --gtf option, so it can read the secondary curve parameters. Slay.

--std <byte1>,<byte2> — shows you the standard timing that these two bytes represent. Just two little bytes and it spills the whole tea ☕
--dmt <dmt> — shows the timings for the DMT with the given DMT ID 🎀
--vic <vic> — shows the timings for this VIC ✨
--hdmi-vic <hdmivic> — shows the timings for this HDMI VIC 🦋
--cvt w=<width>,h=<height>,fps=<fps>[,rb=<rb>][,interlaced][,overscan][,alt][,hblank=<hblank>][,vblank=<vblank>][,early-vsync] — calculates the CVT timings for the given format. Iconic behavior honestly 👑

So like, decoding the deets on this one:

<width> is the width in pixels, and <height> is the frame (not field!) height in lines. Not the field bestie, the frame 🫶
<fps> is frames per second for progressive timings, and fields per second for interlaced timings.
<rb> can be 0 (that means no reduced blanking, and it's the default), or 1-3 for the reduced blanking version.
If interlaced is given, then this is an interlaced format.
If overscan is given, then this is an overscanned format. I.e., margins are required.
If alt is given and <rb>=2, then it reports the timings optimized for video: 1000 / 1001 * <fps>. Math girlie behavior 😭
If alt is given and <rb>=3, then the horizontal blanking is 160 instead of 80 pixels.
If hblank is given and <rb>=3, then the horizontal blanking is <hblank> pixels (range of 80-200 and divisible by 8), and it overrides alt. Queen of override energy 👑
If vblank is given and <rb>=3, then the vertical blanking time is <vblank> microseconds (460 minimum, values > 705 might not be supported by all RBv3 timings compliant source devices. Careful bestie, not every device is built for that 😬
If early-vsync is given and <rb>=3, then it selects an early vsync timing. ✨

--gtf w=<width>,h=<height>[,fps=<fps>][,horfreq=<horfreq>][,pixclk=<pixclk>][,interlaced][,overscan][,secondary][,C=<c>][,M=<m>][,K=<k>][,J=<j>] — calculates the GTF timings for the given format 💖

Breaking it down, no cap:

<width> is the width in pixels, <height> is the frame (not field!) height in lines. Again: frame, not field 🌸
<fps> is frames per second for progressive timings and fields per second for interlaced timings.
<horfreq> is the horizontal frequency in kHz.
<pixclk> is the pixel clock frequency in MHz. And listen: only one of fps, horfreq or pixclk must be given. Pick one, babe, don't be greedy 🙈
If interlaced is given, then this is an interlaced format.
If overscan is given, then this is an overscanned format. I.e., margins are required.
If secondary is given, then the secondary GTF is used for reduced blanking, where <c>, <m>, <k> and <j> are parameters for the secondary curve. If none of the secondary curve parameters were set, and an EDID file is passed as a command line option, then the secondary curve parameters are read from that EDID. It's giving "read the room… and the file" 📖✨
The default secondary curve parameters are 40 for <c>, 600 for <m>, 128 for <k> and 20 for <j>. These values correspond to the normal curve that GTF uses.

--ovt (rid=<rid>|w=<width>,h=<height>),fps=<fps> — calculates the OVT timings for the given format. Either specify a <rid> or specify <width> and <height> (pick a lane, bestie 🎀). <fps> is frames per second.
--list-established-timings — lists all known Established Timings 📋
--list-dmts — lists all known DMTs 📋
--list-vics — lists all known VICs 📋
--list-hdmi-vics — lists all known HDMI VICs 📋
--list-rids — lists all known CTA-861 RIDs 📋
--list-rid-timings <rid> — lists all timings for the specified <rid>, or all known RIDs if <rid> is 0. Zero means "give me everything" and honestly same 💅

🫶 NOTES 🫶

Not all fields are decoded, or decoded completely. Not every part of the vibe gets its moment 😭 edid-decode does attempt to validate its input against the relevant standards, but its opinions have not been double-checked with the relevant standards bodies, so they may be wrong.

Do not rely on the output format, because it will likely change in future versions of the tool as additional fields and extensions are added. It's giving "don't get attached, it's a phase" 💀

The whole friend group, honestly. Go say hi 👋

👑 AUTHORS 👑

edid-decode was written by Adam Jackson, with contributions from Eric Anholt, Damien Lespiau, Hans Verkuil and others. Legends only, fr fr 💖

Bug reports or questions about this utility should be sent to the linux-media@vger.kernel.org mailinglist. Don't be shy, they want to hear from you 🫶

And that's a wrap on EDID-DECODE(1), bestie!! 🎀✨ This page is from v4l-utils 1.32.0, dated November 2024 — yes, a certified fresh drop, we love to see it 💅🌸 Go forth and decode those EDIDs, you absolute icon 👑💜

📦 where this page comes from

alpine 3.24: v4l-utils-doc 1.32.0-r1 · LGPL-2.0-or-later
arch rolling: v4l-utils 1.32.0-2 · LGPL
fedora 43: v4l-utils 1.32.0-1.fc43 · GPL-2.0-or-later AND GPL-2.0-only AND (GPL-2.0-only OR BSD-3-Clause) AND LicenseRef-Fedora-Public-Domain AND HPND-sell-variant
fedora 44: v4l-utils 1.32.0-3.fc44 · GPL-2.0-or-later AND GPL-2.0-only AND (GPL-2.0-only OR BSD-3-Clause) AND LicenseRef-Fedora-Public-Domain AND HPND-sell-variant
nixos 26.05: v4l-utils 1.32.0
nixpkgs unstable: v4l-utils 1.32.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms