企业官网建设流程全解析

1. 显示驱动调试的底层逻辑与工具全景

显示驱动这行当，说白了就是在跟一堆寄存器、时序参数和格式转换打交道。你写进去一个像素值，它得经过图层合成、色彩空间转换、时序控制器，最后变成差分信号送到屏幕上。中间任何一个环节出问题，呈现出来的就是花屏、闪屏、黑屏或者颜色不对。所以调试工具的核心价值，就是让你能在这条链路的每个节点上"插一脚"，看看数据到底长什么样。

我刚开始接触DRM子系统的时候，最头疼的就是不知道从哪下手。内核日志里一堆atomic、plane、crtc的术语，用户空间又有一堆ioctl，感觉像在黑暗中摸开关。后来才慢慢理清楚，显示驱动的调试工具大致可以分成三个层次：内核态的调试接口、用户态的测试工具、以及跨层的日志追踪机制。这三个层次各有各的用处，缺一不可。

内核态这边，debugfs是绝对的主力。DRM子系统在/sys/kernel/debug/dri/下面暴露了大量的调试节点，比如framebuffer、gem_names、state这些。你可以直接cat这些文件，看到当前所有framebuffer的格式、尺寸、修饰符信息。特别是state文件，它会把当前CRTC、plane、encoder的连接状态全部打印出来，对于排查"为什么屏幕不亮"这类问题特别有用。我遇到过好几次，硬件连接都正常，但就是没显示，最后发现是plane没有正确绑定到CRTC上，state文件里一目了然。

用户态这边，modetest是最常用的工具，它来自libdrm的测试套件。这个工具能做的事情非常多：列出所有显示资源、设置显示模式、测试plane合成、验证格式支持。我一般拿到一块新板子，第一件事就是跑modetest -M <driver> -c看看CRTC的状态，再跑modetest -M <driver> -p看看plane的格式支持列表。这两个命令的输出，基本就能判断出驱动有没有正确初始化。

Android系统上情况会复杂一些，因为SurfaceFlinger在上面又包了一层。但底层还是DRM那套东西，只是通过HWC（Hardware Composer）做了抽象。调试的时候，你可以用dumpsys SurfaceFlinger看图层合成状态，用dumpsys display看显示设备信息。如果怀疑是HWC的问题，还可以通过vendor下面的调试节点直接操作DRM。我个人的经验是，Android上的显示问题，先看SurfaceFlinger的合成策略，再看HWC的决策，最后才落到DRM驱动层，这个顺序能帮你快速定位问题在哪一层。

注意：不同厂商的DRM驱动在debugfs节点的命名和内容上可能有差异，但核心的state、framebuffer、gem_names这几个节点基本是通用的。如果找不到某个节点，先确认内核配置里CONFIG_DEBUG_FS和CONFIG_DRM_DEBUGFS有没有打开。

2. 核心调试工具深度拆解与实操要点

2.1 modetest：显示管道的"万用表"

modetest这个工具，我愿称之为显示驱动调试的瑞士军刀。它直接跟DRM设备文件打交道，绕过了所有上层框架，能让你看到最原始的显示状态。安装很简单，Ubuntu上apt install libdrm-tests就行，Android上需要自己交叉编译，源码在libdrm/tests/modetest下面。

先说过最常用的几个参数。-c是查看connector状态，输出里会显示每个connector的ID、类型（HDMI、DP、DSI等）、连接状态（connected/disconnected）、支持的显示模式列表。这里有个细节：connected只表示物理连接检测到了，不代表链路训练成功了。我有一次调试DP显示器，-c显示connected，但屏幕就是没输出，后来用-p看plane状态才发现是链路训练失败导致CRTC没有使能。

-p是查看plane信息，这个输出信息量很大。每个plane会列出支持的格式（比如XR24、AR24、NV12等）、支持的修饰符（modifier）、以及当前绑定的CRTC。格式列表特别重要，如果你要测试视频播放，就得确认plane支持NV12；如果要测试UI合成，就得确认支持AR24（带alpha的RGB）。我遇到过一个问题，UI显示正常但视频播放花屏，最后发现是视频层用的plane不支持NV12，驱动自动转成了XR24，但转换过程中色彩空间搞错了。

-s是设置显示模式，格式是<connector_id>:<crtc_id>:<mode>。比如modetest -M rockchip -s 52:43:1920x1080-60。这里有个坑：mode的名字必须跟-c输出里的完全一致，包括刷新率。有些驱动会生成多个相同分辨率但不同刷新率的mode，选错了可能点不亮。我一般会先用-c把mode列表复制下来，再粘贴到-s参数里。

-w是写属性，这个功能在调试色彩相关问题时特别有用。比如你可以通过-w <plane_id>:<property>:<value>来修改plane的COLOR_ENCODING、COLOR_RANGE这些属性。我调试HDR显示的时候，就是靠这个命令反复切换BT2020和BT709色彩空间，观察屏幕颜色的变化，最终定位到是驱动里色彩空间转换矩阵写错了。

# 列出所有显示资源 modetest -M rockchip -c -p -e # 设置HDMI输出为1080p60 modetest -M rockchip -s 52:43:1920x1080-60 # 修改plane的色彩编码属性 modetest -M rockchip -w 35:COLOR_ENCODING:1

实操心得：modetest的-a参数可以查看所有属性，包括那些不常用的。我建议每次调试新平台时，先跑一遍-a，把关键属性的ID和取值范围记下来，后面用-w的时候就不用反复查了。

2.2 DRM debugfs：内核态的"X光机"

debugfs是内核开发者留给我们的后门，通过它可以直接窥探DRM内部的数据结构。挂载命令很简单：mount -t debugfs none /sys/kernel/debug。然后进入/sys/kernel/debug/dri/目录，你会看到以DRM设备编号命名的子目录，比如0、1。

每个子目录下面有几个关键文件。framebuffer文件列出了当前所有注册的framebuffer，包括ID、尺寸、像素格式、修饰符。这个信息在排查内存泄漏时特别有用——如果你发现framebuffer数量只增不减，那肯定是有地方没有正确释放。我就遇到过一个案例，应用频繁创建销毁Surface，但framebuffer数量一直涨，最后发现是驱动里fb_destroy回调没有正确释放GEM对象。

gem_names文件列出了所有GEM对象的名称和大小。GEM是DRM的图形内存管理器，所有显存分配都要经过它。通过这个文件，你可以看到每个缓冲区的实际大小和用途。如果发现某个缓冲区异常大，或者数量异常多，那可能就是内存泄漏的源头。我一般会结合framebuffer和gem_names一起看，交叉验证。

state文件是最重要的，它把整个显示管道的状态都打印出来了。输出格式是每个CRTC一段，下面跟着绑定的plane、encoder、connector信息。关键要看几个地方：CRTC的active状态、plane的fb_id是否非零、connector的crtc_id是否匹配。如果active是false但connector又显示connected，那说明显示管道没有正确使能。如果plane的fb_id是0，说明这个plane没有绑定任何缓冲区，自然不会显示内容。

还有一个隐藏技巧：你可以往state文件里写东西来触发状态更新。比如echo 1 > state会强制驱动重新计算显示状态。这个在调试热插拔问题时特别有用，有时候拔掉显示器再插上，状态没有正确更新，写一下state就能强制刷新。

# 查看当前framebuffer列表 cat /sys/kernel/debug/dri/0/framebuffer # 查看GEM对象分配情况 cat /sys/kernel/debug/dri/0/gem_names # 查看完整显示状态 cat /sys/kernel/debug/dri/0/state # 强制刷新显示状态 echo 1 > /sys/kernel/debug/dri/0/state

注意：debugfs节点是只读的居多，但state文件可写。写操作可能会触发显示管道的重新配置，在生产设备上慎用，最好在调试版本上操作。

2.3 Android SurfaceFlinger调试：上层视角的合成分析

Android上的显示调试，绕不开SurfaceFlinger。虽然底层还是DRM，但SurfaceFlinger做了大量的合成优化和图层管理，很多显示问题其实出在这一层。dumpsys SurfaceFlinger是最常用的命令，输出信息极其丰富，但也很长，建议重定向到文件再慢慢看。

关键看几个部分。首先是Display Devices，这里列出了所有显示设备的状态，包括分辨率、刷新率、色彩模式。如果发现刷新率不对，或者色彩模式跟预期不符，那就要检查HWC的配置。然后是Layers，这里列出了所有图层的状态，包括Z-order、可见性、缓冲区格式。如果某个图层显示异常，先看它的visible属性是不是true，再看buffer的格式和尺寸。

dumpsys display是另一个重要命令，它从DisplayManagerService的角度看显示设备。这里能看到每个显示设备的state（ON/OFF/DOZE）、brightness、rotation。如果屏幕不亮，先看state是不是OFF，再看brightness是不是0。我有一次遇到屏幕黑屏但背光亮的情况，最后发现是brightness被设成了0，但state还是ON，导致看起来像黑屏。

对于HWC相关的调试，还可以用dumpsys SurfaceFlinger --hwc来查看HWC的决策日志。这个日志会显示每一帧的合成策略：哪些图层用GPU合成，哪些用HWC合成。如果发现某个图层本该用HWC合成却走了GPU，那可能是格式不支持或者缩放比例超限。我调试视频播放性能问题时，就是靠这个日志发现视频层被强制GPU合成，导致功耗偏高。

# 查看SurfaceFlinger完整状态 dumpsys SurfaceFlinger > /data/local/tmp/sf_dump.txt # 查看显示设备状态 dumpsys display # 查看HWC合成决策 dumpsys SurfaceFlinger --hwc

实操心得：dumpsys SurfaceFlinger的输出在不同Android版本上差异很大，建议先确认版本号，再对照对应版本的源码看输出格式。另外，--hwc参数在部分厂商的ROM上可能不支持，如果报错就换用--latency看帧率信息。

3. 典型调试场景与完整实操流程

3.1 场景一：新平台点屏失败排查

拿到一块新板子，接上屏幕，发现完全不亮。这是最常见的场景，也是最能考验调试功力的。我的排查流程一般是这样的：

第一步，确认硬件连接。用万用表量一下背光供电、信号线阻抗，排除硬件问题。这一步虽然简单，但能省掉后面很多无用功。我有一次折腾了半天软件，最后发现是排线没插紧。

第二步，看内核日志。dmesg | grep -i drm，重点看有没有probe success、connector detected、mode valid这些关键字。如果驱动probe都失败了，那后面的都不用看了。常见的问题是电源域没打开、时钟没使能、或者GPIO配置错误。

第三步，用modetest -c看connector状态。如果显示disconnected，那说明HPD（热插拔检测）有问题。先检查HPD引脚的电平，再看驱动里的HPD中断有没有正确注册。如果显示connected但mode列表为空，那说明EDID读取失败。EDID是显示器通过I2C传给主机的，如果I2C通信有问题，就读不到EDID，自然也就没有可用的mode。

第四步，用modetest -s强制设置一个mode。如果-c里没有mode，可以手动指定一个标准mode，比如1920x1080-60。如果设置成功但屏幕还是不亮，那就用modetest -p看plane状态。确认plane的fb_id非零，且绑定的CRTC跟connector一致。

第五步，如果以上都正常但屏幕还是不亮，那就得看时序参数了。用示波器量一下像素时钟、行同步、场同步信号。我遇到过一个问题，驱动里配置的时序参数跟屏幕规格书差了一个像素，导致屏幕无法同步。这种问题只能靠示波器抓波形，软件层面看不出来。

# 查看DRM相关的内核日志 dmesg | grep -i -E "drm|hdmi|dp|dsi" # 查看connector状态 modetest -M rockchip -c # 强制设置显示模式 modetest -M rockchip -s 52:43:1920x1080-60 # 查看plane绑定状态 modetest -M rockchip -p

注意：强制设置mode时，如果驱动不支持该mode，modetest会报错。这时候可以尝试用-w直接写CRTC的MODE_ID属性，但需要先知道mode的blob ID，操作起来更复杂。

3.2 场景二：花屏与颜色异常定位

花屏问题比点屏失败更棘手，因为显示管道是通的，只是数据不对。花屏的表现形式很多：雪花点、条纹、颜色错位、局部闪烁。不同的表现对应不同的问题根源。

雪花点通常是内存带宽不足或者DMA传输错误。用modetest -p看plane的格式，如果格式是NV12但驱动实际按XR24在读取，那就会花屏。这时候需要检查驱动里的格式转换逻辑，确认plane的格式跟framebuffer的格式一致。

条纹问题一般是时序参数不对。用示波器量像素时钟，看频率是否跟mode匹配。如果频率偏差超过1%，就可能出现条纹。另外，行同步和场同步的极性也要跟屏幕规格书一致，反了也会出条纹。

颜色错位通常是色彩空间转换的问题。RGB和YUV之间的转换矩阵如果写错了，颜色就会偏。用modetest -w修改plane的COLOR_ENCODING和COLOR_RANGE属性，观察颜色变化。如果改成BT709就正常了，那说明驱动默认用了BT601，但内容实际是BT709。

局部闪烁可能是plane的alpha混合有问题。检查plane的alpha属性，确认混合模式是premultiplied还是coverage。如果alpha值不对，就会出现闪烁。我遇到过一个案例，UI图层的alpha被设成了0.5，但驱动按coverage模式处理，导致边缘闪烁。

# 查看plane支持的格式 modetest -M rockchip -p | grep -A 20 "Planes" # 修改色彩编码 modetest -M rockchip -w 35:COLOR_ENCODING:1 # 修改色彩范围 modetest -M rockchip -w 35:COLOR_RANGE:1 # 查看plane的alpha属性 modetest -M rockchip -a | grep -i alpha

实操心得：颜色问题最好用标准测试图来排查。我一般会准备一张包含纯红、纯绿、纯蓝、灰阶的图片，显示出来用色度计量一下，看色坐标是否在规格范围内。如果没有色度计，也可以用手机拍屏幕，然后在电脑上取色对比，虽然精度差一些，但能判断出大方向。

3.3 场景三：Android多图层合成性能优化

Android设备上，显示性能问题往往表现为掉帧、卡顿。用dumpsys SurfaceFlinger --latency可以看每一帧的合成耗时。如果某几帧的耗时突然飙高，那就要分析是哪个图层导致的。

先用dumpsys SurfaceFlinger看图层列表，找到耗时高的图层。然后看这个图层的buffer格式和尺寸。如果格式是RGBA8888但实际内容不需要alpha，那就可以改成RGBX8888，减少带宽。如果尺寸是4K但显示区域只有1080p，那就可以在应用层做缩放，减少HWC的缩放开销。

HWC的合成策略也很关键。用dumpsys SurfaceFlinger --hwc看每一帧的合成决策。如果发现某个图层本该用HWC合成却走了GPU，那就要检查这个图层的格式是否被HWC支持。有些HWC只支持特定的格式组合，比如NV12视频层加AR24UI层，如果UI层用了RGBA8888，HWC可能就不支持，只能走GPU。

还有一个容易被忽略的点：图层的Z-order。如果两个图层有重叠，且上面的图层是半透明的，那HWC可能无法直接合成，需要先做混合。这种情况下，可以考虑把半透明图层改成不透明，或者在应用层先做好混合再送显。

# 查看帧率信息 dumpsys SurfaceFlinger --latency # 查看HWC合成决策 dumpsys SurfaceFlinger --hwc # 查看图层详细信息 dumpsys SurfaceFlinger | grep -A 30 "Layers"

注意：不同厂商的HWC实现差异很大，有些厂商的HWC支持更多的格式组合。如果发现HWC不支持某个格式，可以先查厂商的文档，确认是否有特殊的配置要求。

4. 常见问题速查与避坑指南

4.1 工具使用中的典型报错与解决

调试工具用多了，总会遇到各种报错。我把最常见的几个整理成表格，方便快速查阅。

除了这些报错，还有一些"不报错但结果不对"的情况。比如modetest -s执行成功但屏幕没变化，那可能是CRTC没有真正使能。这时候要去看state文件，确认CRTC的active属性是不是true。如果active是false，那说明驱动在设置mode后没有正确使能CRTC，需要检查驱动里的atomic_enable回调。

还有一个常见问题是modetest显示的格式列表跟实际支持的不一致。这通常是因为驱动在atomic_check阶段做了额外的限制，但modetest只读取了atomic_get_property返回的静态列表。这种情况下，只能通过实际测试来确认哪些格式真正可用。

实操心得：我习惯在调试前先跑一遍modetest -a，把所有属性的ID和当前值都记录下来。这样后面用-w的时候，就不用反复查属性ID了。另外，modetest的-v参数可以打印详细的调试信息，遇到奇怪问题时可以加上看看。

4.2 内核日志分析技巧

内核日志是排查显示问题的第一手资料，但很多人不知道怎么高效地看。我的经验是，先过滤关键字，再看上下文。

常用的过滤关键字有：drm、hdmi、dp、dsi、panel、backlight、vblank。用dmesg | grep -i -E "drm|hdmi|dp"可以快速定位到显示相关的日志。如果日志太多，可以用dmesg -T加上时间戳，方便对照操作时间。

看日志的时候，要注意几个关键节点。probe阶段看驱动有没有正确加载，bind阶段看connector有没有正确注册，enable阶段看CRTC有没有正确使能。如果某个阶段失败了，日志里通常会有明确的错误码。比如-ENODEV表示设备不存在，-EINVAL表示参数无效，-ETIMEDOUT表示超时。

还有一个技巧：用echo 8 > /proc/sys/kernel/printk可以提高内核日志的打印级别，让更多调试信息输出到控制台。但这样会产生大量日志，建议只在需要时临时打开，调试完再改回去。

# 查看显示相关的内核日志 dmesg -T | grep -i -E "drm|hdmi|dp|dsi|panel" # 提高日志打印级别 echo 8 > /proc/sys/kernel/printk # 恢复默认日志级别 echo 4 > /proc/sys/kernel/printk

注意：提高日志级别可能会影响系统性能，特别是在高频显示更新的场景下。建议只在排查特定问题时临时使用，问题定位后立即恢复。

4.3 性能问题的排查思路

显示性能问题通常表现为掉帧、卡顿、功耗高。排查思路可以总结为"一看二测三对比"。

一看，是看现象。用dumpsys SurfaceFlinger --latency看帧率，用dumpsys SurfaceFlinger --hwc看合成策略，用top看CPU占用。先确定问题出在哪个环节：是应用渲染慢，还是合成慢，还是显示输出慢。

二测，是测数据。用modetest测plane的格式支持，用debugfs测内存带宽占用，用示波器测时序信号。把各个环节的数据都测出来，才能找到瓶颈。

三对比，是对比不同配置下的表现。比如把图层格式从RGBA8888改成RGBX8888，看帧率有没有提升；把合成策略从GPU改成HWC，看功耗有没有下降。通过对比，就能确定最优配置。

我遇到过一个典型案例：设备播放4K视频时掉帧。用--latency看，发现每帧合成耗时超过16ms。用--hwc看，发现视频层走了GPU合成。检查plane格式，发现视频层是NV12，但HWC只支持NV12加AR24的组合，而UI层用了RGBA8888，导致HWC无法合成。把UI层改成RGBX8888后，HWC就能直接合成，帧率恢复正常。

# 查看帧率 dumpsys SurfaceFlinger --latency # 查看CPU占用 top -n 1 | grep surfaceflinger # 查看内存带宽 cat /sys/kernel/debug/dri/0/gem_names | awk '{sum+=$2} END {print sum}'

实操心得：性能问题往往不是单一原因导致的，而是多个因素叠加。我一般会先解决最明显的瓶颈，再逐步优化其他环节。不要试图一次性解决所有问题，那样容易顾此失彼。

5. 工具链的扩展与自动化调试思路

5.1 从手动调试到脚本化

手动敲命令调试效率很低，特别是需要反复测试不同参数的时候。我后来把常用的调试操作都写成了脚本，一键执行，省时省力。

比如点屏测试脚本，会自动遍历所有connector和mode，尝试设置并检查是否成功。颜色测试脚本，会自动切换不同的色彩编码和范围，并记录屏幕上的颜色变化。性能测试脚本，会自动运行一段时间，收集帧率和功耗数据，生成报告。

脚本化的好处不仅是省时间，更重要的是可重复。手动操作容易漏掉步骤或者输错参数，脚本每次执行都是一样的，结果更可靠。而且脚本可以版本管理，不同平台的调试脚本可以共享和复用。

#!/bin/bash # 自动点屏测试脚本 DRIVER="rockchip" for conn in $(modetest -M $DRIVER -c | grep -oP '^\d+(?=.*connected)'); do echo "Testing connector $conn" for mode in $(modetest -M $DRIVER -c | grep -A 100 "Connector $conn" | grep -oP '\d+x\d+-\d+'); do echo " Trying mode $mode" modetest -M $DRIVER -s $conn:43:$mode 2>&1 | grep -q "failed" || echo " Success" done done

注意：脚本里的CRTC ID（上面的43）需要根据实际情况修改。不同平台的CRTC编号可能不同，建议先用modetest -c确认。

5.2 结合ftrace做深度追踪

当debugfs和modetest都不够用的时候，就得上ftrace了。ftrace是内核的跟踪框架，可以跟踪函数调用、中断、调度等事件。对于显示驱动，最有用的是跟踪drm_atomic_commit相关的函数，看每一次提交的详细过程。

启用ftrace的步骤：先挂载tracefs，然后设置要跟踪的函数，最后读取trace文件。比如要跟踪drm_atomic_commit，可以这样操作：

# 挂载tracefs mount -t tracefs none /sys/kernel/tracing # 设置跟踪函数 echo 'drm_atomic_commit*' > /sys/kernel/tracing/set_ftrace_filter echo function > /sys/kernel/tracing/current_tracer # 开始跟踪 echo 1 > /sys/kernel/tracing/tracing_on # 执行操作（比如modetest设置mode） # 停止跟踪并查看结果 echo 0 > /sys/kernel/tracing/tracing_on cat /sys/kernel/tracing/trace

ftrace的输出会显示每个函数的调用时间、调用者、耗时。通过分析这些数据，可以找到耗时长的函数，定位性能瓶颈。我调试一个vblank超时问题时，就是靠ftrace发现drm_crtc_wait_one_vblank耗时异常，最后定位到是中断处理函数里有死循环。

实操心得：ftrace的输出量很大，建议先用set_ftrace_filter缩小跟踪范围，只跟踪关键函数。另外，trace文件是环形缓冲区，如果输出太多，旧的数据会被覆盖，可以调大buffer_size_kb。

5.3 跨平台调试的注意事项

不同平台的显示驱动差异很大，调试工具的使用方式也不一样。我总结了几点跨平台调试的经验。

首先是设备节点。Linux上通常是/dev/dri/card0，Android上可能是/dev/dri/card0或者/dev/graphics/fb0。有些平台还会创建多个DRM设备，比如一个用于显示，一个用于GPU。用ls /dev/dri/可以确认。

其次是debugfs路径。虽然都是/sys/kernel/debug/dri/，但子目录的编号可能不同。有些平台是0，有些是1。用ls /sys/kernel/debug/dri/确认。

然后是工具版本。modetest的版本要跟libdrm的版本匹配，否则可能出现兼容性问题。Android上的libdrm通常是厂商定制的，功能可能跟上游不一样。如果遇到奇怪的问题，可以先确认工具版本。

最后是权限。Linux上通常需要root权限才能访问DRM设备，Android上也是。如果遇到权限问题，先sudo或者su试试。

# 确认DRM设备节点 ls -l /dev/dri/ # 确认debugfs路径 ls /sys/kernel/debug/dri/ # 确认modetest版本 modetest --version

注意：有些平台的DRM驱动会限制debugfs的访问权限，即使root用户也可能无法读取某些节点。这种情况下，只能通过修改内核配置或者驱动代码来开放权限。

6. 个人调试经验与实用建议

调试显示驱动这些年，踩过的坑比走过的路还多。有些经验是文档里不会写的，只有实际动手才能体会到。

第一个建议：先确认硬件，再调软件。我至少有三次，花了半天时间调软件，最后发现是排线松了或者屏幕坏了。现在我的习惯是，拿到问题先量电压、测信号，确认硬件没问题再动软件。这个顺序能省掉大量无用功。

第二个建议：善用对比法。遇到奇怪的问题，先找一个已知正常的配置，然后逐步修改，看哪一步开始出问题。比如花屏问题，先用标准测试图确认显示管道是通的，再换实际内容，看是不是格式转换的问题。对比法能快速缩小问题范围。

第三个建议：记录每一次修改。调试过程中会尝试很多参数，如果不记录，很容易忘记哪个参数改过、改成什么了。我一般会用文本文件记录每次修改的内容和结果，方便回溯。特别是多人协作的时候，记录更重要。

第四个建议：不要忽视上层框架。很多显示问题其实出在SurfaceFlinger或者HWC，而不是DRM驱动。先看上层日志，再往下查，能少走很多弯路。我遇到过一个案例，屏幕闪烁，查了半天DRM没发现问题，最后发现是SurfaceFlinger的vsync配置错了。

第五个建议：保持工具更新。libdrm和modetest都在持续更新，新版本可能修复了旧版本的bug，或者增加了新功能。我一般会定期从上游拉最新代码编译，确保用的是最新版本。

实操心得：调试显示问题时，最好准备一个"最小复现环境"。比如一个最简单的测试程序，只做显示初始化，不涉及其他模块。这样能排除其他因素的干扰，快速定位问题。我一般会用modetest作为最小复现工具，因为它足够简单，又足够强大。

最后分享一个我常用的调试命令组合，基本上能覆盖80%的显示问题：

# 一键收集显示调试信息 { echo "=== DRM Devices ===" ls -l /dev/dri/ echo "=== Connectors ===" modetest -M rockchip -c echo "=== Planes ===" modetest -M rockchip -p echo "=== Framebuffers ===" cat /sys/kernel/debug/dri/0/framebuffer echo "=== GEM Objects ===" cat /sys/kernel/debug/dri/0/gem_names echo "=== DRM State ===" cat /sys/kernel/debug/dri/0/state echo "=== Kernel Log ===" dmesg | grep -i -E "drm|hdmi|dp|dsi|panel" | tail -50 } > /data/local/tmp/display_debug.txt

这个脚本会把所有关键信息收集到一个文件里，方便离线分析。我一般会在问题复现后立即执行，避免日志被覆盖。收集到的信息可以发给同事或者厂商支持，能大大加快问题定位速度。

显示驱动调试是个细活，需要耐心和细心。工具只是辅助，关键还是对显示管道的理解。把DRM的架构搞清楚，知道每个组件的作用和相互关系，调试起来就会事半功倍。希望这些经验能帮到正在踩坑的你。