显示驱动板卡HDMI与DP接口协议兼容性实战：从链路训练到EDID解析

显示驱动板卡这个行当，最让人头疼的从来不是画板子或者调背光，而是接口协议兼容性。你手里那块板子，HDMI 口插上显示器能亮，换一台电视就黑屏；DP 口接笔记本正常，接扩展坞就掉链路。这类问题在实验室里复现不出来，到了客户现场却一抓一个准。我做了十多年显示驱动硬件和底层调试，踩过的兼容性坑比调通的板子还多。这篇内容就是把这些年关于显示驱动板卡接口协议兼容性的实战经验整理出来，从 HDMI 和 DP 的底层握手机制，到 EDID 解析、IIC 通信、固件更新、链路训练，再到实际排查的完整链路，全部讲透。不管你是刚入行的硬件工程师，还是做了几年驱动开发想补上协议层知识的老手，都能从里面找到能直接用的东西。

1. 显示驱动板卡上 HDMI 与 DP 的协议栈差异到底在哪

很多人把 HDMI 和 DP 都当成"视频线"来理解，觉得只要物理接口对得上、线材没问题，就应该能出图。这个认知在消费电子层面勉强成立，但在显示驱动板卡的设计和调试层面，是完全不够用的。HDMI 和 DP 虽然都传输视频和音频，但它们的协议栈设计哲学、链路建立方式、时钟架构、甚至热插拔检测的电气特性都不一样。理解这些差异，是解决兼容性问题的第一步。

1.1 HDMI 的 TMDS 架构与 DP 的微包架构

HDMI 用的是 TMDS（Transition Minimized Differential Signaling）架构。简单说，它把视频像素、音频数据、控制信息全部编码成三个差分通道上的串行数据流，外加一个独立的 TMDS 时钟通道。接收端靠这个独立时钟来采样三个数据通道。这种设计的好处是接收端不需要从数据流里恢复时钟，硬件实现相对简单。但代价是时钟通道必须始终存在，而且时钟频率和像素时钟严格绑定。一旦分辨率或刷新率变化，时钟通道的频率也要跟着变，链路需要重新建立。

DP 走的是完全不同的路子。它用的是微包（Micro-Packet）架构，把视频、音频、控制信息打包成一个个传输单元，通过一到四条主链路（Main Link）发送。DP 没有独立的时钟通道，接收端需要从数据流里做时钟恢复（Clock Recovery）。这意味着 DP 的链路训练过程比 HDMI 复杂得多，需要经过时钟恢复、通道均衡、符号锁定、通道对齐等多个阶段。好处是 DP 的扩展性更强，一条链路可以动态分配带宽，支持多流传输（MST），而且可以通过 AUX 通道做双向通信。

这个差异直接导致了一个常见现象：HDMI 接口在分辨率切换时容易出现短暂黑屏或闪烁，因为时钟通道需要重新锁定；而 DP 接口在链路训练失败时可能直接不亮，因为时钟恢复阶段就没过去。你在调试时如果看到 HDMI 切换分辨率闪一下就好，那是正常的；但 DP 如果第一次就没亮，大概率是链路训练出了问题。

1.2 热插拔检测与 HPD 信号的电气差异

HDMI 的热插拔检测（HPD）信号是接收端（显示器）给源端（板卡）的一个电平信号。显示器插上后，HPD 拉高，源端检测到高电平后开始读取 EDID，然后决定输出什么分辨率。这个信号是单向的，而且电平标准是 5V。很多板卡的 HPD 检测电路设计得比较粗糙，直接用电阻分压或者光耦隔离，结果遇到某些显示器 HPD 驱动能力不足，或者线材压降太大，源端就检测不到。

DP 的 HPD 信号则是双向的，而且和 AUX 通道配合使用。DP 的 HPD 不仅表示"我插上了"，还表示"我准备好了"或者"我需要你重新训练链路"。DP 的 HPD 脉冲宽度、时序要求比 HDMI 严格得多。我遇到过一块板子，HDMI 口接任何显示器都能识别，但 DP 口接某品牌的显示器就是不出图，后来用示波器抓 HPD 信号才发现，那块显示器的 HPD 脉冲宽度只有 1ms 左右，而板卡的 HPD 检测中断响应时间超过了 2ms，直接漏掉了。

注意：HDMI 的 HPD 是 5V 电平，DP 的 HPD 是 3.3V 电平。如果你在板卡上共用 HPD 检测电路，一定要做电平转换，否则长期工作可能损坏 DP 接收端。

1.3 EDID 读取机制的异同

EDID（Extended Display Identification Data）是显示器告诉源端"我是谁、我支持什么分辨率、我的时序参数是什么"的标准数据结构。HDMI 和 DP 都使用 EDID，但读取方式不同。HDMI 通过 DDC（Display Data Channel）读取，本质上就是 IIC 总线，地址是 0x50。DP 则通过 AUX 通道读取，AUX 是一种半双工的双向通信协议，物理层和 IIC 完全不同。

这个差异带来的实际问题是：很多板卡的 HDMI EDID 读取用硬件 IIC 控制器，而 DP 的 AUX 读取需要专门的 AUX 控制器或者用 GPIO 模拟。如果你在固件里把两者搞混了，或者 AUX 时序没调好，就会出现"HDMI 能读 EDID，DP 读不到"的情况。更麻烦的是，有些显示器的 EDID 数据超过 256 字节，需要分块读取（Extension Block），HDMI 和 DP 的分块读取流程也不一样。

我在实际项目中总结了一个经验：HDMI 的 EDID 读取失败，十有八九是 IIC 时序或者上拉电阻的问题；DP 的 EDID 读取失败，十有八九是 AUX 通道的差分信号完整性或者 AUX 控制器配置的问题。两者的排查方向完全不同，不要混为一谈。

2. 接口协议兼容性问题的根因分类与排查链路

兼容性问题最怕的就是"时好时坏"和"换个设备就不行"。这类问题如果靠猜，能把你耗死。我习惯把兼容性问题分成几大类，每一类有对应的排查链路和工具。下面这套分类方法是我在多个量产项目中验证过的，基本能覆盖 90% 以上的接口兼容性故障。

2.1 物理层兼容性：线材、连接器与信号完整性

物理层问题是最容易被忽视的，因为大家总觉得"线材能插上就行"。但 HDMI 和 DP 的高速信号对线材的要求非常高。HDMI 2.0 的 TMDS 速率最高到 6Gbps per lane，DP 1.4 的 HBR3 速率是 8.1Gbps per lane。这个速率下，线材的阻抗匹配、插入损耗、回波损耗都会直接影响链路能否建立。

我遇到过一批板子，在实验室用短跳线测试全部通过，到了客户现场用标配的 1.5 米线材，有 30% 的机器出现间歇性黑屏。后来用眼图分析仪抓了一下，发现那批线材的差分阻抗偏离 100 欧姆太多，导致信号反射严重。换了一批线材后问题消失。这个案例告诉我们，兼容性测试一定要用实际出货的线材，不能用实验室的"理想线材"。

排查物理层问题的工具和步骤：

排查链路建议按这个顺序走：先确认线材和连接器没问题，再用示波器抓 HPD 和 AUX 信号，最后用协议分析仪看链路训练日志。不要一上来就怀疑芯片固件，物理层的问题占了兼容性故障的一半以上。

2.2 链路训练失败：DP 特有的兼容性难题

DP 的链路训练（Link Training）是兼容性问题的重灾区。链路训练分几个阶段：时钟恢复（Clock Recovery）、通道均衡（Channel Equalization）、符号锁定（Symbol Lock）、通道对齐（Lane Alignment）。每个阶段都可能因为信号质量、接收端均衡能力、训练参数配置等原因失败。

我印象最深的一次是某块板子接某品牌的 4K 显示器，DP 就是不出图。用协议分析仪抓链路训练过程，发现时钟恢复阶段就失败了。后来查接收端的 DPCD（DisplayPort Configuration Data）寄存器，发现那块显示器要求的训练参数（如预加重、电压摆幅）和板卡默认配置不匹配。板卡默认用的是最低档的预加重和电压摆幅，而那块显示器因为线材损耗大，需要更高的预加重才能恢复时钟。手动调整训练参数后问题解决。

这个案例说明，DP 链路训练不能完全依赖自动协商，有时候需要根据实际线材和显示器特性做手动干预。很多板卡的固件里有一个"训练参数表"，针对不同的线材长度和显示器类型预设不同的参数。如果你的板子没有这个机制，遇到兼容性问题就只能改固件。

2.3 EDID 解析错误：分辨率不匹配的隐形杀手

EDID 解析错误是另一个高频兼容性问题。显示器的 EDID 里包含了它支持的所有分辨率和时序参数，源端需要根据 EDID 选择一个双方都支持的最佳分辨率。如果 EDID 解析出错，源端可能选了一个显示器不支持的分辨率，结果就是黑屏或者花屏。

EDID 解析错误的原因很多：EDID 数据本身有错误（有些廉价显示器的 EDID 是随便写的）、IIC 读取过程中数据被干扰、解析算法有 bug、或者源端和接收端对某些时序参数的理解不一致。我见过最离谱的一个案例是，某显示器的 EDID 里把 1920x1080 的像素时钟写错了，导致源端算出来的时序参数完全不对，出图就是花屏。后来在固件里加了一个 EDID 校验和修正逻辑，才解决这个问题。

排查 EDID 问题的步骤：

1. 用工具读取显示器的原始 EDID 数据，保存成二进制文件。
2. 用 EDID 解析工具（如 AW EDID Editor）打开，检查每个字段是否合理。
3. 对比源端实际输出的分辨率和 EDID 里声明的最佳分辨率是否一致。
4. 如果 EDID 数据有问题，考虑在固件里做修正或者强制指定分辨率。

提示：有些显示器的 EDID 在热插拔后会变化，或者在不同接口下 EDID 不同。测试时一定要覆盖冷启动、热插拔、不同接口等多种场景。

3. HDMI 接口兼容性实战：从 IIC 通信到视频旋转

HDMI 接口的兼容性问题，很多时候集中在 IIC 通信和视频处理上。HDMI 的 DDC 通道本质上就是 IIC，但它的时序要求比标准 IIC 更严格，而且很多板卡的 IIC 控制器配置不当，导致 EDID 读取失败或者 HDCP 认证失败。另外，视频旋转这个需求在嵌入式显示驱动板卡上越来越常见，但 HDMI 输入的视频旋转处理会引入额外的兼容性问题。

3.1 HDMI 的 IIC 通信时序与常见故障

HDMI 的 DDC 通道使用 IIC 协议，时钟频率标准是 100kHz，但很多显示器支持更高速率。问题在于，HDMI 规范对 IIC 的时序要求比标准 IIC 更严格，特别是起始条件、停止条件和时钟拉伸（Clock Stretching）的处理。

我遇到过一块板子，HDMI 接某品牌显示器时 EDID 读取成功率只有 50%。用示波器抓 SCL 和 SDA 信号，发现板卡的 IIC 控制器在发送起始条件后，没有正确处理显示器的时钟拉伸。显示器在准备 EDID 数据时需要拉低 SCL 来暂停传输，但板卡的 IIC 控制器不支持时钟拉伸，直接继续发时钟，导致数据错位。后来换了一个支持时钟拉伸的 IIC 控制器，问题解决。

HDMI IIC 通信的常见故障和解决方法：

还有一个容易被忽视的点：HDMI 的 IIC 总线上通常挂载多个设备（EDID、HDCP 密钥等），地址冲突或者总线负载过重也会导致通信失败。我在设计板卡时，习惯在 IIC 总线上加一个缓冲器，把 EDID 和其他设备隔离开，这样即使某个设备出问题，也不会影响整个总线。

3.2 HDMI 输入在 RK3566 上的兼容性处理

RK3566 是很多显示驱动板卡常用的主控芯片，它内置了 HDMI 输入接口。但在实际使用中，RK3566 的 HDMI 输入兼容性有一些需要注意的地方。首先是 EDID 的读取，RK3566 的 HDMI 输入控制器支持硬件 IIC，但默认配置可能不兼容某些显示器。我遇到过接某品牌电视时 EDID 读取失败，后来在设备树里调整了 IIC 时钟频率和超时时间，问题解决。

其次是 HDMI 输入的分辨率检测。RK3566 的 HDMI 输入支持自动检测输入分辨率，但检测算法在某些非标准分辨率下会出错。比如输入是 1366x768 这种非标准分辨率时，RK3566 可能识别成 1280x720，导致显示异常。解决方法是在驱动里强制指定输入分辨率，或者用 EDID 里的详细时序描述符（Detailed Timing Descriptor）来精确匹配。

另外，RK3566 的 HDMI 输入和输出共用一些硬件资源，如果同时使用输入和输出，可能会出现带宽不足或者时钟冲突。我在一个双 HDMI 的项目中，就遇到了输入和输出同时工作时，输出端出现闪烁的问题。后来通过调整时钟树和带宽分配，才解决这个问题。

3.3 HDMI 视频旋转的实现与兼容性代价

HDMI 视频旋转是一个看起来简单但实现起来很麻烦的需求。旋转本身可以用 GPU 或者专门的旋转芯片来做，但问题在于旋转会引入额外的延迟和带宽消耗，而且可能影响 HDCP 认证和 EDID 协商。

我做过一个项目，需要把 HDMI 输入的横屏视频旋转 90 度显示到竖屏上。最初方案是用 GPU 做旋转，但发现 GPU 旋转会引入大约 2 帧的延迟，而且在高分辨率下 GPU 带宽不够，导致掉帧。后来改用专门的旋转芯片，延迟降到 0.5 帧以内，但新的问题出现了：旋转芯片会修改视频时序，导致某些显示器无法识别。

这个问题的根因是，旋转后的视频时序和原始时序不同，显示器需要重新锁定。如果旋转芯片输出的时序不符合显示器的要求，就会黑屏。解决方法是让旋转芯片输出标准的时序，或者在 EDID 里声明旋转后的分辨率。但 EDID 是显示器提供的，源端不能修改，所以只能在源端做时序转换。

注意：HDMI 视频旋转会改变像素时钟和时序参数，如果板卡的 HDMI 输出控制器不支持动态时序调整，旋转后可能无法出图。选型时一定要确认主控的 HDMI 输出是否支持动态时序。

4. DP 接口兼容性实战：链路训练、AUX 通道与固件更新

DP 接口的兼容性问题比 HDMI 更复杂，因为 DP 的链路训练和 AUX 通信都是双向的，任何一个环节出问题都会导致链路建立失败。而且 DP 的固件更新（Update DP Firmware）也是一个容易被忽视的兼容性因素，不同版本的固件对链路训练参数的处理可能不同。

4.1 DP 链路训练的完整流程与失败点分析

DP 链路训练是一个多阶段的过程，每个阶段都有明确的成功条件和失败处理机制。理解这个流程，对于排查兼容性问题至关重要。

链路训练的主要阶段：

1. 时钟恢复（Clock Recovery）：接收端从数据流中恢复时钟，调整均衡器参数。这个阶段失败通常是因为信号质量太差或者预加重/电压摆幅配置不当。
2. 通道均衡（Channel Equalization）：进一步调整均衡器，优化信号质量。这个阶段失败通常是因为线材损耗太大或者接收端均衡能力不足。
3. 符号锁定（Symbol Lock）：接收端锁定数据流的符号边界。这个阶段失败通常是因为时钟抖动太大或者数据模式不匹配。
4. 通道对齐（Lane Alignment）：多条主链路的通道对齐。这个阶段失败通常是因为通道间偏斜（Skew）太大。

每个阶段失败后，源端会尝试调整参数重新训练，最多尝试几次。如果所有尝试都失败，链路就建立不起来。我在调试时，习惯用协议分析仪抓取完整的训练日志，看是在哪个阶段失败，然后针对性地调整参数。

一个常见的误区是，很多人认为链路训练失败一定是硬件问题。实际上，固件里的训练参数配置、训练重试次数、超时时间等软件因素也会导致训练失败。我遇到过一块板子，硬件信号质量很好，但固件里的训练超时时间设得太短，导致接收端还没来得及完成均衡就被判定为失败。把超时时间从 10ms 改成 50ms 后，问题解决。

4.2 AUX 通道通信故障的排查方法

AUX 通道是 DP 的"控制通道"，负责读取 EDID、DPCD 寄存器、链路训练参数等。AUX 通道的物理层是差分信号，速率是 1Mbps，比 IIC 快得多，但也更脆弱。

AUX 通信故障的常见表现是：EDID 读取失败、DPCD 寄存器读写错误、链路训练参数无法协商。排查 AUX 故障，我通常按这个顺序走：

1. 用示波器抓 AUX 差分信号，看波形是否正常。AUX 是半双工差分信号，空闲时两条线都是高电平，通信时一条拉低。如果波形异常，检查 AUX 收发器电路和终端电阻。
2. 用协议分析仪抓 AUX 通信日志，看是否有应答超时、奇偶校验错误、或者命令被拒绝。
3. 检查 AUX 控制器的配置，包括时钟频率、超时时间、重试次数等。
4. 如果 AUX 通信正常但 EDID 读取失败，检查 EDID 数据的地址映射和分块读取逻辑。

我遇到过一个案例，AUX 通信在冷启动时正常，但热插拔后就失败。后来发现是 AUX 收发器的电源在上电时序上有问题，热插拔时电源跌落导致收发器复位。调整电源时序后问题解决。这个案例说明，AUX 故障不一定是通信协议的问题，电源和复位时序也要检查。

4.3 DP 固件更新对兼容性的影响

DP 固件更新（Update DP Firmware）是很多板卡厂商用来修复兼容性问题的常用手段。但固件更新本身也可能引入新的兼容性问题。我见过太多案例，更新固件后原本能用的显示器不能用了，或者原本不能用的显示器能用了但另一个又不行了。

固件更新影响兼容性的主要方面：

• 链路训练参数：不同固件版本可能使用不同的预加重、电压摆幅、均衡器配置。这些参数对不同的显示器和线材组合效果不同。
• EDID 解析逻辑：固件更新可能修改 EDID 解析算法，导致某些显示器的 EDID 被错误解析。
• AUX 通信协议：固件更新可能修改 AUX 通信的超时时间、重试次数等参数。
• HDCP 认证流程：固件更新可能修改 HDCP 认证的流程，导致某些显示器认证失败。

我的经验是，固件更新一定要做完整的兼容性回归测试，覆盖所有已知的显示器和线材组合。不要只测试一两个"常用"显示器就发布固件。另外，固件更新最好支持回滚，万一新固件有问题，可以快速恢复到旧版本。

5. 兼容性测试体系与量产阶段的稳定性保障

兼容性问题在实验室里很难完全暴露，很多问题要到量产或者客户现场才出现。所以，建立一套完整的兼容性测试体系，比单纯解决某个具体问题更重要。这套体系包括测试矩阵设计、自动化测试工具、以及量产阶段的筛选机制。

5.1 兼容性测试矩阵的设计原则

兼容性测试矩阵的核心是"覆盖足够多的组合"。显示器和线材的组合数量是巨大的，不可能全部测试。所以需要根据市场占有率和客户反馈，选择有代表性的组合。

我设计测试矩阵时，通常按这几个维度来选：

• 显示器品牌：选择市场占有率前 5 的品牌，每个品牌选 2-3 款不同定位的产品。
• 分辨率：覆盖 1080p、2K、4K，以及一些非标准分辨率如 1366x768、2560x1080。
• 刷新率：覆盖 60Hz、120Hz、144Hz，以及可变刷新率（VRR）。
• 线材长度：覆盖 0.5m、1m、1.5m、2m、3m，以及不同品质的线材。
• 接口类型：HDMI 2.0、HDMI 2.1、DP 1.2、DP 1.4，以及 Type-C 转 DP/HDMI。

这个矩阵组合下来，大概有 100-200 个测试用例。全部手动测试不现实，所以需要自动化测试工具。

5.2 自动化兼容性测试工具链

自动化测试的核心是"自动切换输入源、自动检测输出、自动记录结果"。我搭建过一套基于树莓派和继电器的自动化测试系统，成本不高但很实用。

系统组成：

• 主控：树莓派或者小型工控机，运行测试脚本。
• 继电器板：控制显示器的电源和输入源切换。
• 摄像头：拍摄显示器画面，用图像识别判断是否出图、是否花屏。
• 协议分析仪：抓取 HDMI/DP 的通信日志，记录链路训练过程。
• 测试脚本：Python 脚本，控制继电器、读取摄像头图像、解析协议日志、生成测试报告。

这套系统可以 24 小时不间断运行，自动遍历测试矩阵，记录每个组合的测试结果。我实际用下来，发现了很多手动测试漏掉的问题，比如某个显示器在热插拔 100 次后 EDID 读取失败率上升，这种问题手动测试根本发现不了。

5.3 量产阶段的兼容性筛选与固件策略

到了量产阶段，兼容性问题的处理策略要转变。实验室阶段是"发现问题、解决问题"，量产阶段是"筛选出有问题的板子、保证出货质量"。

量产阶段的兼容性筛选通常包括：

• EDID 读取测试：每块板子都要读取标准显示器的 EDID，确认 IIC/AUX 通信正常。
• 链路训练测试：用标准线材和显示器，确认链路能正常建立。
• 热插拔测试：模拟多次热插拔，确认 HPD 检测和 EDID 重读正常。
• 固件版本校验：确认每块板子的固件版本一致，避免混版。

固件策略方面，我建议采用"基线固件 + 补丁"的方式。基线固件是经过完整兼容性测试的稳定版本，补丁是针对特定显示器或线材的兼容性修复。量产时烧录基线固件，遇到特定兼容性问题时再打补丁。这样可以保证大部分板子的稳定性，同时灵活处理个别兼容性问题。

提示：量产阶段的兼容性测试一定要用实际出货的线材和显示器，不能用实验室的样品。我见过太多案例，实验室测试全过，量产用实际线材就出问题。

6. 几个真实兼容性故障的完整排查过程

理论讲再多，不如看几个真实的排查案例。下面这三个案例是我在实际项目中遇到的，每个都花了很长时间才定位到根因。我把完整的排查链路写出来，希望能帮你少走弯路。

6.1 案例一：HDMI 接某品牌电视间歇性黑屏

现象：板卡 HDMI 输出接某品牌 4K 电视，大约每 10 分钟黑屏 1-2 秒，然后恢复。接其他品牌电视和显示器正常。

排查过程：

1. 首先怀疑线材，换了三根不同品牌的 HDMI 2.0 线材，现象依旧。
2. 用示波器抓 TMDS 时钟和数据信号，发现黑屏时时钟信号有短暂的抖动。
3. 用协议分析仪抓 HDMI 通信日志，发现黑屏时电视发送了 HPD 脉冲，但板卡没有正确响应。
4. 检查 HPD 检测电路，发现板卡的 HPD 检测中断优先级太低，被其他中断阻塞，导致响应延迟。
5. 调整中断优先级后，问题解决。

根因：HPD 中断响应延迟，导致板卡错过了电视的 HPD 脉冲。电视在检测到链路质量下降时会发送 HPD 脉冲请求重新训练，板卡没响应，电视就黑屏重试。

6.2 案例二：DP 接扩展坞链路训练失败

现象：板卡 DP 输出接某品牌扩展坞，扩展坞再接显示器，链路训练失败，显示器不亮。板卡直接接显示器正常。

排查过程：

1. 用协议分析仪抓链路训练日志，发现时钟恢复阶段就失败了。
2. 检查扩展坞的 DPCD 寄存器，发现扩展坞要求的预加重等级比显示器高。
3. 板卡默认使用最低档预加重，信号经过扩展坞后衰减太大，接收端无法恢复时钟。
4. 在固件里增加预加重等级的动态调整逻辑，根据接收端的 DPCD 请求自动调整。
5. 更新固件后，问题解决。

根因：扩展坞引入了额外的信号衰减，板卡默认的训练参数不够。需要根据实际链路损耗动态调整预加重和电压摆幅。

6.3 案例三：EDID 解析错误导致分辨率不匹配

现象：板卡 HDMI 输出接某品牌显示器，出图但分辨率不对，显示器显示 1920x1080 但画面被拉伸。

排查过程：

1. 读取显示器 EDID，发现 EDID 里声明的最佳分辨率是 1920x1080，但详细时序描述符里的像素时钟是 148.5MHz，而标准 1080p60 的像素时钟应该是 148.5MHz，看起来没问题。
2. 仔细检查 EDID 的其他字段，发现 EDID 的扩展块里有一个额外的时序描述符，声明了一个 1920x1080 但像素时钟是 74.25MHz 的时序。
3. 板卡的 EDID 解析算法优先选择了扩展块里的时序，导致输出 1080i 而不是 1080p。
4. 修改 EDID 解析算法，优先选择详细时序描述符里的第一个时序，问题解决。

根因：EDID 解析算法对扩展块的处理有误，选择了错误的时序。很多显示器的 EDID 扩展块里会有多个时序描述符，解析算法需要正确选择。

这三个案例的共同点是：问题都不在硬件本身，而在固件和配置。兼容性问题很多时候是"软"问题，需要从协议层和固件层去排查。我的经验是，遇到兼容性问题，先用协议分析仪抓日志，看通信过程哪里出了问题，然后再针对性地检查硬件和固件。不要一上来就换芯片或者改板子，那样成本太高，而且不一定能解决问题。

最后分享一个我在实际项目中总结的小技巧：建立自己的"兼容性数据库"，记录每个测试过的显示器和线材的 EDID、DPCD、链路训练参数、以及遇到的问题和解决方法。下次遇到类似问题时，先查数据库，往往能快速定位。这个数据库我积累了五年，现在遇到新问题，80% 都能在里面找到参考。