17.1 dmesg日志分析驱动工程师的第一道防线dmesg说白了就是内核的“日记本”。驱动干了什么、报了什么错全记在里面。怎么用最基础的命令就这几个# 查看所有日志 dmesg # 只看DRM相关的 dmesg | grep drm # 只看MTK显示相关的 dmesg | grep -i mtk_drm # 实时监控像tail -f一样 dmesg -w我个人习惯在调试多屏时会同时开三个终端一个跑dmesg -w一个跑logcat一个留着敲命令。这样任何风吹草动都逃不过我的眼睛。关键日志解读多屏初始化成功时你会看到类似这样的输出[ 5.123456] mtk_drm: primary display initialized, width1080, height1920 [ 5.234567] mtk_drm: external display detected on HDMI [ 5.345678] mtk_drm: external display initialized, width1920, height1080如果出现timeout waiting for vsync或buffer underrun那基本就是时序或带宽问题。我的小技巧dmesg日志默认只保留最近的一圈。如果你要排查开机阶段的显示问题建议在init.rc里加上logcat -b all 或者用dmesg -n 7把级别调到最低。我曾经因为日志被冲刷掉多浪费了半天时间。17.2 trace_event追踪精准定位时序问题dmesg能看到“发生了什么”但看不到“什么时候发生的”。这时候就需要trace_event出马了。启用方法MTK平台下显示相关的trace点一般在/sys/kernel/debug/tracing/events/drm/目录下。# 挂载debugfs mount -t debugfs none /sys/kernel/debug # 查看可用的trace事件 ls /sys/kernel/debug/tracing/events/drm/ # 启用所有drm事件 echo 1 /sys/kernel/debug/tracing/events/drm/enable # 开始追踪 echo 1 /sys/kernel/debug/tracing/tracing_on # 跑你的测试用例... # 停止追踪 echo 0 /sys/kernel/debug/tracing/tracing_on # 查看结果 cat /sys/kernel/debug/tracing/trace你想想看当你要排查“副屏画面比主屏慢了两帧”这种问题时trace_event能精确告诉你每一帧的提交时间、完成时间、vsync时间点。这比靠肉眼盯着屏幕看靠谱多了。注意trace_event会带来一定的性能开销。生产环境不要开调试时用完记得关掉。我曾经在客户现场演示时忘了关trace结果帧率直接掉了一半...场面一度非常尴尬。17.3 drm_info工具显示状态的“体检报告”drm_info是DRM子系统自带的调试工具能帮你把显示链路的状态看得一清二楚。安装与使用在MTK平台上drm_info通常已经编译进系统。如果没有可以从external/drm_info编译。# 查看所有显示设备 drm_info # 查看指定connector的详细信息 drm_info -c 0 # 查看crtc状态 drm_info -p输出解读这是我之前在MTK8678开发板上跑出来的结果Connector 0 (HDMI-A-1) Status: connected Modes: 1920x108060Hz (preferred) 1280x72060Hz 720x48060Hz Encoder 0 (TMDS) CRTC 0 Mode: 1920x108060Hz Active: yes Vblank: enabled Connector 1 (DSI-1) Status: connected Modes: 1080x192060Hz (preferred) Encoder 1 (DSI) CRTC 1 Mode: 1080x192060Hz Active: yes Vblank: enabled看到没主屏是HDMI副屏是DSI两个都activevblank都开了。如果某个屏幕显示不正常先看这里——是不是connector没连上是不是crtc没激活实战经验有一次客户反馈副屏不亮我远程连上去跑了个drm_info发现connector状态是disconnected。再一查原来是HDMI的HPD引脚虚焊了。这种问题没有drm_info你根本不知道是硬件问题还是软件问题。17.4 FPS测量方法用数据说话做显示驱动帧率是硬指标。客户不会听你解释“感觉挺流畅的”他们要的是数字。方法一dumpsys SurfaceFlinger这是最常用的方法不需要root# 查看所有窗口的帧率 adb shell dumpsys SurfaceFlinger --latency # 只看某个特定窗口 adb shell dumpsys SurfaceFlinger --latency SurfaceView方法二使用perfettoMTK平台推荐用perfetto它能同时抓取CPU、GPU、显示三个维度的数据# 启动perfetto追踪 adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto \ -t 10s \ sched freq idle idle freq gpu_mem gpu_freq \ drm:* # 拉取到PC分析 adb pull /data/misc/perfetto-traces/trace.perfetto方法三自己写fps测量工具嗯这里要注意。有时候你需要精确到每一帧的时间戳这时候我会写一个简单的C程序#include stdio.h #include time.h #include unistd.h int main() { struct timespec ts; long long last_ns 0, current_ns; int frame_count 0; while (1) { clock_gettime(CLOCK_MONOTONIC, ts); current_ns ts.tv_sec * 1000000000LL ts.tv_nsec; if (last_ns ! 0) { long long delta current_ns - last_ns; double fps 1000000000.0 / delta; printf(Frame %d: %.2f FPS (interval: %.3f ms)\n, frame_count, fps, delta / 1000000.0); } last_ns current_ns; usleep(16667); // 模拟60fps的vsync间隔 } return 0; }我的测量心得测量fps时一定要在真实负载下测。空载时跑60fps不代表什么要在播放视频、滑动列表、打开相机这些场景下测。我一般会写一个自动化脚本让手机跑10分钟的各种场景然后取平均值和最低值。最低值才是用户体验的瓶颈。17.5 四件套配合使用一个真实案例最后我跟你分享一个真实案例看看这四个工具怎么配合使用。有一次客户说副屏播放视频时偶尔会卡顿。我是这么排查的先看dmesg发现mtk_drm: buffer underrun on external display的警告说明是buffer问题。再用trace_event追踪buffer的提交和释放时间发现GPU提交buffer的速度跟不上显示消耗的速度。然后用drm_info确认副屏的刷新率是60Hz但实际vblank间隔不稳定有时会跳到70Hz。最后测fps用perfetto抓了10秒数据发现副屏fps在45-60之间波动主屏稳定60fps。最终定位到问题副屏的clock源配置有误导致vblank时序不稳定。修改clock配置后问题解决。你看这四个工具就像医生的听诊器、CT机、血压计和心电图。单独用哪个都能发现问题但配合起来才能精准定位。下次遇到显示问题别急着改代码。先跑一遍这四件套让数据告诉你问题在哪。