EDID编程规范：从128字节到256字节的显示端配置与校验指南

简介这份EDID编程规范文档面向显示器固件开发、显卡驱动调试及嵌入式显示接口工程师用于解决显示终端与信号源之间识别数据不匹配、时序配置错误等兼容性问题。资源包内含1个doc文件约493KB以文字规范与数据结构表为主便于查阅与对照编写。文档系统梳理了EDID V1.3的128字节基本数据结构及256字节扩展方式逐段讲解第零区域文件头、生产厂家与产品识别、版本号、基本显示参数、色彩特性、确定与标准显示时序、详细时序描述、显示终端名称及行场频范围限制、扩展标志与CheckSum等字段的地址分配与默认取值并给出640×48085Hz等标准时序的字节换算示例。目前已有552人学习适合需要快速掌握EDID字段含义、校验和计算与编程要点的开发者参考。1. EDID 编程规范从 128 字节到 256 字节一份能直接烧录的显示端配置手册调过显示驱动的人都遇到过这种场景板子通电屏幕背光亮了但画面死活出不来或者分辨率被强行拉到 640×480怎么改驱动参数都没用。折腾半天最后发现问题不在驱动而在显示器那 256 字节的 EDID 数据里——时序描述块写错了或者 Checksum 对不上信号发生器直接拒绝输出。EDIDExtended Display Identification Data扩展显示识别数据就是显示终端通过 DDC 通道告诉信号源“我是谁、我能吃什么信号”的那份身份证。它定义了一个基本的 128 字节结构并可在此基础上扩展到 256 字节。这份编程规范把 V1.3 版本从文件头到 Checksum 的每一个字节都拆开了适合做显示驱动、TV 主板、HDMI 接口固件的工程师直接照着填表。下面按“结构拆解 → 逐块编写 → 扩展块处理 → 校验排查”的顺序走一遍。2. EDID 基本块拆解128 字节里哪几个地址动不得2.1 第零区域块的文件头与厂商识别区EDID 的前 8 个字节是固定的地址 00h 到 07h 必须写成00 FF FF FF FF FF FF 00。这组值不是随便定的它是判断一份 EDID 是否合法的第一道门槛。我见过有人用工具生成 EDID 后手动改了几个字节结果文件头被覆盖系统直接当没插显示器处理。所以不管后面怎么改这 8 个字节不要碰。紧接着 08h 到 11h 是生产厂家和产品识别区。08h 到 09h 是厂商名称用 5 位二进制压缩编码表示三个字母比如0x42 0x49对应的是某厂商代号。0Ah 到 0Bh 是产品代码规范里建议为保持通用性一般不用默认填00 00。0Ch 到 0Fh 是产品序列号同样默认01 00 00 00。10h 是生产周数11h 是生产年份年份的计算方式是“实际年份减去 1990”比如 2007 年就填0x11。这几个字节在功能验证阶段可以先用默认值等整份 EDID 跑通了再回填真实信息。2.2 版本号、基本参数与色彩特性12h 和 13h 分别是 EDID 的主版本号和修订号。V1.3 就填01 03V1.4 填01 04。这里有个容易翻车的地方版本号决定了后续字节的解析规则如果你写的是 1.3 但按 1.4 的格式填了扩展块解析端会按 1.3 的规则去读结果就是时序全乱。14h 到 18h 是基本显示参数。14h 是输入信号定义模拟输入默认0Eh数字输入默认80h。这个字节直接决定信号源用哪种方式跟显示器握手填错了就是黑屏。15h 和 16h 是屏幕最大水平和垂直尺寸单位是厘米一般不用可以填00。17h 是 gamma 值计算公式是(gamma × 100) - 100gamma 2.2 对应0x78。18h 是支持的特性标志默认EAh。19h 到 22h 是色彩特性区共 10 个字节通常保持默认值色温 9300K。除非产品对色域有特殊要求否则不建议在这里做文章因为色坐标的编码方式比较绕改错一个 bit 就会导致偏色。2.3 确定时序与标准时序识别23h 到 25h 是确定的显示时序3 个字节每一位对应一组预设的显示模式。比如 bit0 对应 640×480 60Hzbit1 对应 800×600 60Hz。规范里给的示例是21 64 00表示选了 640×480 60Hz 和 800×600 60Hz。这一段的选择逻辑很简单你的屏幕能支持哪些常规模式就把对应位置 1。不选的就保持 0。26h 到 35h 是标准的显示时序识别区16 个字节可以放 8 组时序每组 2 字节。但规范里明确说了“该段数据一般不用默认值为 01h”。如果你确实需要在这里填一组非预设的时序编码方式是这样的第一个字节是(水平有效像素 / 8) - 31第二个字节的 bit7 和 bit6 表示宽高比00 是 16:1001 是 4:310 是 5:411 是 16:9bit5 到 bit0 是刷新率减去 60。举个例子640×480 85Hz宽高比 4:3第一个字节是640/8 - 31 49即31h第二个字节宽高比 01刷新率 85-6025即19h组合起来就是59h。最终填31 59。注意标准时序区如果不用16 个字节全部填01h不要填00h。填00h在某些解析器里会被当成有效时序去解析导致识别异常。3. 详细时序描述块18 字节里把点频、消隐、同步全算清楚3.1 详细时序描述 1 和 2 的字段拆解36h 到 47h 是详细时序描述 148h 到 59h 是详细时序描述 2每个块 18 字节。这 18 个字节的字段排列是固定的但计算方式需要对着公式一步步来。以规范里给出的 1920×1080i 60Hz 为例点频 74.25MHz地址 36h 填0137h 填1D。点频的编码方式是“点频值MHz× 100再拆成高低字节”74.25×1007425十六进制是1D01低字节在前就是01 1D。38h 到 39h 是行活动像素1920 对应80 18低字节在前。3Ah 是行消隐像素280 对应18。3Bh 到 3Ch 是场活动线数540 对应1C 02。3Dh 是场消隐线数22 对应16。3Eh 是行同步偏移像素88 对应58。3Fh 是行同步宽度44 对应2C。40h 是场同步偏移线数和场同步宽度规范里 2/5 对应25高 4 位是偏移低 4 位是宽度。41h 到 42h 是图像尺寸水平 708mm 对应C4垂直 398mm 对应8E。43h 是水平边框44h 是垂直边框都填00。45h 是标志位9E表示这是详细时序描述块。详细时序描述 2 的格式完全一样只是数值不同。规范里给的 720×480p 59.94Hz 示例点频 27MHz编码为8C 0A行活动像素 720 对应D0 02行消隐 138 对应8A场活动线数 480 对应E0 01场消隐 45 对应2D行同步偏移 16 对应10行同步宽度 62 对应3E场同步偏移/宽度 9/6 对应96图像尺寸 531mm×398mm 对应13 8E标志位18。3.2 显示终端名称与行场频范围限制5Ah 到 6Bh 是显示终端描述区其中 5Ah 到 5Eh 是标识头固定为00 00 00 FC 00。5Fh 到 6Bh 是名称内容用 ASCII 码填写结束符是0Ah剩余空间填20h。规范里的示例填的是“PRI HDMI TV”对应字节序列50 52 49 20 48 44 4D 49 20 54 56 0A 20。如果这段不用整个 5Ah 到 6Bh 全部填01h。6Ch 到 7Dh 是行场频范围限制标识头 6Ch 到 70h 固定为00 00 00 FD 00。71h 是最低场频72h 是最高场频73h 是最低行频74h 是最高行频75h 是最大点频单位 MHz除以 10 后取整。规范示例里最低场频 59Hz 填3B最高场频 61Hz 填3D最低行频 15KHz 填0F最高行频 46KHz 填2E最大点频 80MHz 填08。76h 是默认值填0077h 是结束符0A78h 到 7Dh 填20h。3.3 扩展标志与 Checksum 的计算7Eh 是扩展标志。如果只有基本块 128 字节填00如果有扩展块到 256 字节填01。7Fh 是第零区域的 Checksum计算方式是地址 00h 到 7Eh 共 127 个字节的累加和加上 Checksum 值结果必须为00h即 256 的倍数。用 Python 算的话就是def calc_checksum(data): data 为 0x00 到 0x7E 的 127 字节列表 total sum(data) 0xFF return (0x100 - total) 0xFF # 示例假设前 127 字节已经填好 edid_block [0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00] [0x00] * 119 checksum calc_checksum(edid_block) print(fChecksum: 0x{checksum:02X})这段代码的逻辑很直接把 127 个字节求和后取低 8 位然后用 256 减去这个值得到的结果就是 Checksum。参数说明data必须是长度为 127 的列表对应地址 00h 到 7Eh。如果算出来的 Checksum 是0x00说明原始数据本身就已经是 256 的倍数这种情况直接填00即可。注意Checksum 是整份 EDID 最容易翻车的地方。改任何一个字节Checksum 必须重算。我见过有人改完时序忘了重算烧录后显示器直接不识别排查了半天才发现是校验和不对。4. 扩展块编写VGA/DVI 与 HDMI 两种接口的分叉处理4.1 只支持 VGA 或 DVI 的扩展块结构扩展块共 128 字节地址从 00h 到 7Fh。如果信号接口只支持 VGA 或 DVI结构比较简单00h 到 03h 是文件头04h 到 15h 是详细时序描述 316h 到 7Eh 是预留空间默认填007Fh 是 Checksum。文件头的固定值是02 01 04 00。00h 填02表示 CEA 扩展头01h 填01表示 EIA/CEA-861 修订版本号02h 填04是固定值03h 填00。详细时序描述 3 的 18 字节格式和基本块里的详细时序描述完全一样规范里给的示例是 1280×720p 60Hz点频 74.25MHz 编码为01 1D行活动像素 1280 对应00 05行消隐 370 对应72场活动线数 720 对应D0 02场消隐 30 对应1E行同步偏移 110 对应6E行同步宽度 40 对应28场同步偏移/宽度 5/5 对应55图像尺寸 708mm×398mm 对应C4 8E标志位1E。4.2 HDMI 扩展块的音频信息标志与数据块排列如果接口支持 HDMI扩展块的结构就复杂得多。00h 填0201h 填03EIA/CEA-861B 修订版本号02h 是支持音频信息标志的起始地址记为 d。03h 到 (d-1)h 是 HDMI 支持的视频、音频模式、喇叭和厂商描述区。(d)h 是支持音频信息标志后面跟着若干个 18 字节的详细时序描述块最后是预留空间和 Checksum。03h 这个字节很关键它的高 4 位是 DTV 支持功能的状态标志bit7 表示是否支持欠扫描bit6 表示是否支持基本声音格式bit5 表示是否支持 YCBCR 4:4:4bit4 表示是否支持 YCBCR 4:2:2。低 4 位是详细时序描述块的数目。规范示例里填的是53二进制0101 0011表示支持基本声音格式和 YCBCR 4:2:2详细时序描述有 3 个。04h 开始是数据块选取区每个数据块的第一个字节包含标签代码和字节数。标签代码的定义是1 是音频数据块2 是视频数据块3 是厂商描述数据块4 是喇叭安置数据块。规范示例里 04h 填47表示视频数据块后面跟 7 个字节共支持 7 种视频模式。05h 到 0Bh 是具体的视频模式确认代码比如85对应 1920×1080i 59.94/60Hz 16:904对应 1280×720p 59.94/60Hz 16:9。0Ch 填26表示音频数据块共 6 个字节。0Dh 填09表示支持 Linear PCM 音频格式最大通道数 2。0Eh 填07表示支持 32kHz、44.1kHz、48kHz 取样率。0Fh 填07表示支持 16bit、20bit、24bit 比特率。10h 填15表示支持 AC3 音频格式最大通道数 6。11h 填07取样率同上。12h 填50最大音频比特率 640K。13h 填83表示喇叭安置数据块共 3 个字节。14h 填01表示前左右声道。15h 和 16h 填00。17h 填65表示厂商描述数据块共 5 个字节。18h 到 1Ah 是 24-bit IEEE 注册标识03 0C 00。1Bh 填10表示第一个 HDMI 通道。1Ch 填00。1Dh 填80这是 HDMI 支持音频信息标志表示 HDMI 通道支持音频信息处理能够接收和处理 ACP、ISRC1、ISRC2 数据包。4.3 扩展块的详细时序与 Checksum1Eh 到 2Fh、30h 到 41h、42h 到 53h、54h 到 65h 分别是详细时序描述 1 到 4。规范里特别提到美洲机型选用场频 60Hz 的时序欧洲机型选用 50Hz 的时序内销机型 50Hz 和 60Hz 皆可。写入时序时一个模式的 4:3 和 16:9 要同时写入。66h 到 7Eh 是预留空间默认填007Fh 是 Checksum计算方式和基本块一样。def build_hdmi_extension(): 构建一个 HDMI 扩展块的骨架 ext [0x00] * 128 ext[0x00] 0x02 # CEA 扩展头 ext[0x01] 0x03 # EIA/CEA-861B 修订版本号 ext[0x02] 0x1D # 支持音频信息标志起始地址 ext[0x03] 0x53 # DTV 支持功能 详细时序描述数目 # 视频数据块 ext[0x04] 0x47 ext[0x05:0x0C] [0x85, 0x04, 0x11, 0x80, 0x27, 0x90, 0xA0] # 音频数据块 ext[0x0C] 0x26 ext[0x0D:0x13] [0x09, 0x07, 0x07, 0x15, 0x07, 0x50] # 喇叭安置数据块 ext[0x13] 0x83 ext[0x14:0x17] [0x01, 0x00, 0x00] # 厂商描述数据块 ext[0x17] 0x65 ext[0x18:0x1D] [0x03, 0x0C, 0x00, 0x10, 0x00] # HDMI 支持音频信息标志 ext[0x1D] 0x80 # 计算 Checksum total sum(ext[0x00:0x7F]) 0xFF ext[0x7F] (0x100 - total) 0xFF return ext这段代码构建了一个 HDMI 扩展块的骨架参数说明ext[0x02]设为0x1D表示音频信息标志从地址 1Dh 开始ext[0x03]设为0x53表示支持基本声音格式和 YCBCR 4:2:2有 3 个详细时序描述视频数据块和音频数据块的内容按规范示例填充。最后自动计算 Checksum避免手动算错。5. 避坑与排查EDID 烧录后不显示的五个常见原因5.1 现象显示器背光亮但无画面系统识别不到显示器原因第零区域的文件头被覆盖或者 Checksum 计算错误。文件头必须是00 FF FF FF FF FF FF 00任何一个字节不对解析端直接丢弃整份 EDID。Checksum 错误同样会导致数据被判定为无效。解决用二进制工具打开 EDID 文件检查前 8 个字节是否和规范一致。然后用脚本重算 Checksum对比 7Fh 的值。如果文件头正确但 Checksum 不对重新计算后烧录。5.2 现象分辨率被限制在 640×480无法切换到更高模式原因详细时序描述块里的点频或行场参数填错导致解析端认为该模式不可用。比如点频编码时高低字节写反了或者行活动像素的计算方式搞错了。解决逐字节核对详细时序描述块的 18 个字段。点频是“MHz × 100”后低字节在前行活动像素是“像素值”低字节在前场活动线数是“线数”低字节在前。用规范里的示例数据做对照确认每个字段的编码方式。5.3 现象HDMI 接口有画面但无声音原因音频数据块没有正确写入或者 HDMI 支持音频信息标志没有置为0x80。音频数据块的标签代码必须是 1后面的字节要正确定义音频格式、通道数、取样率和比特率。解决检查扩展块里音频数据块的起始地址和字节数。确认 0Dh 到 12h 的音频描述字段符合实际硬件能力。检查 1Dh 地址的值是否为0x80如果不是HDMI 通道不会处理音频信息包。5.4 现象欧洲机型出现画面抖动或闪烁原因详细时序描述块选用了 60Hz 的时序但欧洲机型通常要求 50Hz。场频不匹配会导致画面抖动。解决根据机型销售区域选择对应的场频。美洲机型用 60Hz欧洲机型用 50Hz内销机型两者皆可。写入时序时一个模式的 4:3 和 16:9 要同时写入避免切换宽高比时找不到对应时序。5.5 现象扩展标志为 01 但系统只读取 128 字节原因扩展块的 Checksum 错误或者扩展块的文件头不符合规范。扩展块的文件头 00h 必须是0201h 根据协议版本填01或03。解决检查扩展块的 00h 和 01h 是否符合规范。重算扩展块的 Checksum确保 00h 到 7Eh 的累加和加上 7Fh 等于 256 的倍数。如果扩展块内容为空7Fh 填00即可。6. 用 Python 做一份 EDID 的自动化校验与生成手动填 256 个字节容易出错我一般会写一个校验脚本把规范里的检查表转成代码。下面这个脚本覆盖了文件头、Checksum、扩展标志和详细时序描述块的基本校验import struct def validate_edid(data): 校验一份 256 字节的 EDID 数据 errors [] # 检查文件头 if data[0x00:0x08] ! bytes([0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00]): errors.append(第零区域文件头错误) # 检查第零区域 Checksum if sum(data[0x00:0x7F]) % 256 ! 0: errors.append(第零区域 Checksum 错误) # 检查扩展标志 if data[0x7E] 0x01: if len(data) 256: errors.append(扩展标志为 01 但数据不足 256 字节) else: if data[0x80] ! 0x02: errors.append(扩展块文件头错误) if sum(data[0x80:0xFF]) % 256 ! 0: errors.append(扩展块 Checksum 错误) # 检查详细时序描述块标志位 for offset in [0x36, 0x48]: if data[offset] 0x00 and data[offset1] 0x00: continue # 未使用的描述块 if data[offset0x11] not in [0x18, 0x1E]: errors.append(f详细时序描述块 0x{offset:02X} 标志位异常) return errors # 示例读取一份 EDID 文件并校验 with open(edid.bin, rb) as f: edid_data f.read() result validate_edid(edid_data) if result: for err in result: print(f[FAIL] {err}) else: print([PASS] EDID 校验通过)这段脚本的逻辑是先检查文件头是否匹配固定值再验证第零区域和扩展块的 Checksum 是否为 256 的倍数然后检查扩展标志和扩展块文件头最后检查详细时序描述块的标志位是否为18或1E。参数说明data是完整的 EDID 二进制数据长度至少 128 字节如果有扩展块则应为 256 字节。offset遍历的是两个详细时序描述块的起始地址offset0x11是标志位所在的字节位置。实际用的时候我会把这个脚本挂到编译流程里每次生成 EDID 后自动跑一遍。从那以后我每次改完 EDID 都强制走一遍校验脚本再也没出现过烧录后不显示的低级问题。希望帮到你。本文还有配套的精品资源点击获取