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那套东西只是通过HWCHardware 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的角度看显示设备。这里能看到每个显示设备的stateON/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时如果驱动不支持该modemodetest会报错。这时候可以尝试用-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层用了RGBA8888HWC可能就不支持只能走GPU。还有一个容易被忽略的点图层的Z-order。如果两个图层有重叠且上面的图层是半透明的那HWC可能无法直接合成需要先做混合。这种情况下可以考虑把半透明图层改成不透明或者在应用层先做好混合再送显。# 查看帧率信息 dumpsys SurfaceFlinger --latency # 查看HWC合成决策 dumpsys SurfaceFlinger --hwc # 查看图层详细信息 dumpsys SurfaceFlinger | grep -A 30 Layers注意不同厂商的HWC实现差异很大有些厂商的HWC支持更多的格式组合。如果发现HWC不支持某个格式可以先查厂商的文档确认是否有特殊的配置要求。4. 常见问题速查与避坑指南4.1 工具使用中的典型报错与解决调试工具用多了总会遇到各种报错。我把最常见的几个整理成表格方便快速查阅。报错信息可能原因解决方法modetest: failed to open device权限不足或设备节点不存在用sudo运行或确认/dev/dri/card0存在modetest: no connectors found驱动未正确初始化检查内核日志确认DRM驱动probe成功modetest: failed to set modemode不被支持或CRTC被占用用-c确认mode列表用-p确认CRTC空闲debugfs: no such file or directorydebugfs未挂载执行mount -t debugfs none /sys/kernel/debugdumpsys: permission denied非root用户用adb root或su切换到rootSurfaceFlinger: no display found显示设备未注册检查HWC初始化日志确认显示设备被正确识别除了这些报错还有一些不报错但结果不对的情况。比如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 # 自动点屏测试脚本 DRIVERrockchip 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 \dx\d-\d); do echo Trying mode $mode modetest -M $DRIVER -s $conn:43:$mode 21 | 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/traceftrace的输出会显示每个函数的调用时间、调用者、耗时。通过分析这些数据可以找到耗时长的函数定位性能瓶颈。我调试一个vblank超时问题时就是靠ftrace发现drm_crtc_wait_one_vblank耗时异常最后定位到是中断处理函数里有死循环。实操心得ftrace的输出量很大建议先用set_ftrace_filter缩小跟踪范围只跟踪关键函数。另外trace文件是环形缓冲区如果输出太多旧的数据会被覆盖可以调大buffer_size_kb。5.3 跨平台调试的注意事项不同平台的显示驱动差异很大调试工具的使用方式也不一样。我总结了几点跨平台调试的经验。首先是设备节点。Linux上通常是/dev/dri/card0Android上可能是/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的架构搞清楚知道每个组件的作用和相互关系调试起来就会事半功倍。希望这些经验能帮到正在踩坑的你。