Android显示驱动：DRM/KMS、HWC和SurfaceFlinger

很多人一听到Android显示驱动第一反应是调个LCD初始化代码能亮屏就算会了。如果这么想说明你还没真正进显示驱动这个门。我前前后后摸了几年的Android图形显示栈从最早给一颗国产SoC调一块MIPI DSI屏到后来追SurfaceFlinger的合成问题、查Hardware Composer的validate/present卡顿再到用DRM/KMS做多屏异显这条链路每一层都踩过坑、填过土。这篇文章想把Android显示驱动从0到1的完整学习路线一次捋清楚内核的fbdev/DRM驱动怎么起步HAL层的HWC怎么打通上层的SurfaceFlinger又是怎么消耗你这些驱动的以及每个阶段最实用的调试手段是什么。适合刚接触Android BSP的嵌入式驱动工程师、想做图形栈优化的应用开发者以及所有想系统性搞懂显示子系统的人。1. 入门门槛与前置知识1.1 到底什么样的基础才算够我不建议完全零基础直接一头扎进显示驱动。最理想的起跑线是两条C语言熟练能看懂Linux内核里常见的指针、链表、回调函数有少量Linux驱动经验比如做过GPIO、I2C、串口的字符设备驱动能理解platform_driver、device tree、中断下半部这些概念。如果没有驱动基础也不是不能学但至少要花两周先补Linux内核基础不然你在看drm_panel和drm_bridge的probe流程时会非常痛苦因为这一层拿的是一个接一个的抽象对象稍不留神就绕晕了。如果已经有Android系统开发经验理解Framework层的逻辑会快很多反过来如果是纯驱动出身建议也了解一下Android的应用层事务和BufferQueue否则你没法理解HWC为什么设计成两段式提交。显示驱动不是孤立的点亮屏幕它必须和上层图形栈配合才能保证流畅和稳定。1.2 学习开始前需要准备的环境工欲善其事必先利其器建议按顺序准备一台Linux开发机最好Ubuntu 20.04/22.04内存32G以上磁盘500G以上因为AOSP和内核源码都很占空间AOSP源码可以只拉指定分支比如android-13重点目录frameworks/native/libs/gui、frameworks/native/services/surfaceflinger、hardware/libhardware/modules/hwcomposer、device/xxx的overlay配置一份匹配的内核源码重点目录drivers/gpu/drm、drivers/video/fbdev、include/uapi/drm一块真实的开发板或者一台带屏幕的Android手机/平板最好支持fastboot方便替换内核和system镜像显示器接口的入门知识MIPI DSI、eDP、HDMI、LVDS至少要认识能看懂datasheet里的时序参数。环境搭建是大头别图省事跳过。很多人在macOS或者Windows上装个模拟器就想学显示驱动那是不现实的显示驱动最终要跑在真实硬件上模拟器只能帮你验证逻辑层无法验证时序、电源、背光这些真正出问题的点。1.3 先建立整条链路的心智模型学习显示驱动最忌讳的是只见树木不见森林。我建议在写第一行代码之前先在脑子里建立一条完整的数据流App在Surface上画画Surface的数据通过BufferQueue交给SurfaceFlingerSurfaceFlinger再把所有图层交给HWC去做合成HWC通过DRM/KMS或fbdev把最终画面交给显示控制器最后显示控制器通过DSI/eDP/HDMI把像素时钟发到屏上。这条链路里任何一环断了表现出来就是黑屏、花屏、闪屏、卡顿、延迟。我带的每个人第一周我不会让他碰代码就让他画这条链路的图直到他能把每一层用的关键结构体名字填进去为止。这个习惯真的受益终身遇到显示问题你会惯性思考这一层的输入是什么、输出给谁、正常状态是什么定位速度会快很多。2. 内核显示驱动从fbdev到DRM/KMS2.1 为什么现在学的是DRM/KMS而不是老式fbdev很多以前做过Linux显示的老工程师会习惯性地说framebuffer很简单啊open /dev/fb0mmap一下直接写像素不就行了。确实fbdev在早年确实爽但它的缺点也极其明显没法干净地支持多屏、没法做平面plane叠加、没有标准的属性查询接口、和现代GPU的buffer管理脱节。Linux内核早在4.x时代就开始把fbdev往DRM/KMS迁移现在你说想新做一个显示驱动上游基本默认就是写DRM驱动。DRM/KMS和fbdev的本质区别在于fbdev是把一个像素缓冲区暴露给用户态而KMS是把显示控制器的一组抽象对象暴露给用户态。这些对象包括对象作用类比CRTC控制显示时序扫描显示帧电视机内部的扫描引擎Encoder负责把像素信号编码为物理接口信号信号调制器Connector代表一个物理连接器/屏幕电视机的输入口Plane可独立合成的一个图像层幻灯机的每一层Framebuffer一块由内存或显存构成的图像缓冲区播放的幻灯片这些对象的关系是Framebuffer内容由Plane读取Plane把数据交给CRTCCRTC生成时序送EncoderEncoder把信号发到Connector去驱动屏幕。你可以理解成一套乐高积木每个积木都能独立替换。看懂这张关系图后面学任何具体平台的驱动都会快很多。2.2 先搞懂一个DRM驱动的三大块一个典型的DRM/KMS驱动哪怕再复杂拆开来看也就三块。第一块是驱动框架本身包含drm_driver结构体、probe函数、以及设备注册。这一块基本上每个驱动都一样重点是理解drm_dev_alloc/drm_dev_register、drm_mode_config_init这些API的作用。你只要写过一次后面就是套模板。第二块是mode settingKMS部分包含你如何注册CRTC、Encoder、Connector、Plane以及你如何实现atomic_check和atomic_commit两个核心回调。atomic_check是这个配置我能不能接受atomic_commit是去把这个配置实际写进硬件。任何一个参数不合法都应当在atomic_check阶段被拒绝而不是到了commit阶段发生黑屏。新手经常忽略这个分工把一堆校验逻辑塞进commit等到哪里出错了根本分不清是校验失败还是硬件写入失败。第三块是buffer管理部分包含你如何从DMA-BUF/ION拿到物理地址、如何把Framebuffer映射到Display Controller的地址空间、如何做页面翻转page flip以及release fence。很多新手在这里卡住因为不理解dma-buf的fd和dma地址之间的关系。简单说fd是让你能在用户态传递和引用这个buffer的句柄而dma地址是驱动真正写进显示控制器寄存器用的物理地址两者通过gem对象关联起来。2.3 一个最小DRM驱动大概长什么样我会用一个小骨架来说明不要指望它能在真机上跑但它能帮你建立结构上的感觉static const struct drm_driver my_drm_driver { .driver_features DRIVER_MODESET | DRIVER_ATOMIC, .lastclose drm_fb_helper_lastclose, .name my-drm, .desc My First DRM Driver, .date 20250101, .major 1, .minor 0, }; static int my_drm_probe(struct platform_device *pdev) { struct drm_device *drm; struct my_drm_private *priv; struct drm_connector *connector; struct drm_encoder *encoder; struct drm_crtc *crtc; struct drm_plane *primary; drm drm_dev_alloc(my_drm_driver, dev); if (IS_ERR(drm)) return PTR_ERR(drm); drm_mode_config_init(drm); drm-mode_config.min_width 0; drm-mode_config.min_height 0; drm-mode_config.max_width 1920; drm-mode_config.max_height 1080; // 初始化一个CRTC并给CRTC挂一个primary plane crtc my_drm_crtc_init(drm); primary my_drm_plane_init(drm, DRM_PLANE_TYPE_PRIMARY); // 初始化encoder与connector encoder my_drm_encoder_init(drm); connector my_drm_connector_init(drm); drm_connector_attach_encoder(connector, encoder); drm_dev_register(drm, 0, 0); platform_set_drvdata(pdev, priv); return 0; }真正做产品时你还得实现drm_panel、drm_bridge这样的辅助框架它们负责泛化屏幕和转接芯片。比如你的屏是DSI接口一般会写一个drm_panel的driver在panel_probe里解析device tree的时序并在panel_prepare/panel_enable里做上电、初始化、背光点亮。这才是日常调屏的重点。2.4 调试DRM/KMS最常用的三板斧这里分享三个我几乎每天都会用的工具/命令。modetest这是libdrm自带的工具能列出所有DRM设备及其对象也能强制输出一个测试画面。如果modetest能出画面至少能说明KMS链路是通的问题大概率在上层HWC/SurfaceFlinger。drm_info可以输出atomic state查看当前每个plane的状态、crtc的模式、connector的link status非常适合定位驱动看起来没报错但画面不对的问题。dmesg debugfs内核驱动出问题一般从这里找。常用的debugfs位置是/sys/kernel/debug/dri/0/state可以看到当前所有对象的状态。调试小技巧先只做一个primary plane手动画一个纯色或者简单的黑白棋盘格确定KMS链路没有毛病再往上接HWC。我从没见过谁能一上来就把整条链跑通而不出错的逐步验证是最稳的办法。2.5 内核阶段最容易踩的坑上电时序错了DSI屏对power sequence极敏感reset拉低的时间、VCI和VDD上电的先后稍有不对就出现开机logo一闪而过或者完全黑屏。建议严格按照屏厂datasheet的时序图在panel_prepare里用gpiod_set_value一个脚一个脚地控制并且在每次状态切换之间加足延迟宁慢勿快。背光和显示通道混在一起很多人把背光PWM和DSI数据通道的使能顺序搞反。记住一个原则先让panel起来再亮背光否则会闪屏甚至灼屏。忽略了clock和lane数配置MIPI DSI的lanes数量和clock频率必须和屏的规格完全一致否则会出现花屏、串扰、或者无法正常初始化。这些参数通常在device tree里配置改一次就要重新验证一次时序。3. HAL层与Hardware Composer3.1 HWC存在的意义是什么内核搞定了不等于Android就跑起来了。因为Android不会直接使用modetest的接口来刷屏它要通过HAL层的Hardware ComposerHWC去操作显示硬件。HWC的作用可以一句话概括把SurfaceFlinger送过来的多个图层用硬件合成为一帧然后送给显示控制器。为什么不让SurfaceFlinger自己软件合成因为软件合成所有图层需要GPU把所有图层都读一遍再混合写一遍既耗电又慢。硬件合成器可以在片上集成一个或多个overlay plane直接把几路图层叠加出来省了GPU的读和写。你把它理解成显示硬件把多个透明片叠在一起给你看就明白为什么叫Composer了。3.2 HWC接口的演进路线HWC从1.x一路演到4.x每一代都有清晰的动机。HWC 1.x还是单一设备接口SurfaceFlinger直接拿着Layer列表往里塞HWC 2.x引入了Display和Layer粒度的API支持多Display和更灵活的合成策略HWC 3.x在2.x基础上做了接口清理很多东西从HAL层挪到了common库HWC 4.x进一步强调纯VNDK化HAL的实现必须和framework彻底解耦方便支持Treble架构和Mainline模块化。现在新平台基本都是HWC 3.x或4.x的实现但你在阅读AOSP源码时还会遇到大量HWC2的影子因为很多实现类都还继承自HWC2。我的建议是把HWC2的核心流程吃透HWC3和HWC4的差异就是API壳子的变化内核思想一致不要被版本号吓到。3.3 HWC2里最关键的两段式提交HWC2整个工作的核心可以浓缩成两个阶段。Validate阶段SurfaceFlinger把这一帧所有图层的属性宽高、格式、变换、alpha、geometry告诉HWCHWC要去判断哪些图层可以走Device合成即硬件overlay plane直接显示哪些图层必须走Client合成即GPU先把它们合成到一块临时buffer里再作为一个图层交给Device显示。这个阶段本质是一个规划动作。Present阶段HWC按照Validate的结果把标注为Device的图层配上plane把Client图层作为一块特殊buffer配上plane然后触发一次硬件提交把画面真正刷到屏幕上。这两段的设计非常巧妙。SurfaceFlinger给每一层都标了变化与否HWC就能只在需要变化时重新规划合成路径减少纹理上传和合成工作量。用一段伪代码来表达// 每帧流程 status_t Hwc2Device::onFrameCommit(...) { // 1. 收集SurfaceFlinger传来的图层 std::vectorHwc2Layer layers collectLayers(); // 2. Validate uint32_t numTypes 0, numChanges 0; mImpl-validateDisplay(display, numTypes, numChanges); // 3. 根据validate结果决定合成路径 for (auto layer : layers) { if (layer.compositionType HWC2_COMPOSITION_DEVICE) { assignPlane(layer); } else { // Client合成需要GPU先混合 markAsClient(layer); } } // 4. Present int32_t retireFence -1; mImpl-presentDisplay(display, retireFence); }3.4 合成策略Device vs Client这是最核心的决策。Device合成的上限取决于硬件overlay plane的数量和格式限制。比如某颗SoC可能只有两个支持RGB格式的plane一个支持YUV的plane并且alpha只有在plane 0上才有效。这些限制必须在Validate阶段准确建模否则HWC会把一个本该走Device的层误判成Client导致性能下降更糟的是可能出现颜色错误或丢层。合成策略的调度逻辑在drm_hwcomposer这类开源实现里会做得非常细包括维护plane的分配状态对图层进行排序判断格式、色域、变换是否匹配把不能Device合成的图层合并到一个shared buffer交给GPU做Client合成解决同一条显示链路上多图层互相遮挡的问题。我见过很多性能问题最后都查到了HWC合成策略过于保守把所有层都扔给GPU。正确的做法是根据实际图层数量和格式尽量多让Device合成接管。3.5 用drm_hwcomposer来落地如果你用的是主流SoC一般不需要完全从零实现HWC而是直接适配drm_hwcomposer这个开源项目。它把DRM/KMS的atomic接口映射成了HWC的接口所以前面内核阶段学的DRM知识在这里就能派上用场。drm_hwcomposer的关键模块有DrmDevice封装了DRM设备及所有对象、DrmConnector/Crtc/Plane对应KMS对象、DrmDisplay代表一个物理显示设备内部有合成策略、Planner和CompositionPlanner负责图层到plane的分配、HwcLayer和HwcDisplay作为HWC HAL层和drm层之间的粘合层。学习建议不要一上来就通读所有代码先看HwcDisplay::Present或者CompositionPlanner类的逻辑搞清楚一次validate/present是怎么把HWC的数据翻译成DRM atomic请求的。3.6 HWC层的常用验证手段dumpsys SurfaceFlinger --latency 窗口名查看每帧渲染延迟能看出是SurfaceFlinger慢了还是HWC慢了。dumpsys display查看Display相关的HWC状态。cat /sys/kernel/debug/dri/0/state确认DRM atomic state是否和HWC规划一致。/sys/kernel/debug/dri/0/ 下的framebuffer信息能看到当前分配的buffer。如果HWC上报的错误是No planes available、Client composition required等基本说明合成策略出了问题要么是plane数量不够要么是图层格式触发了Client回退。4. SurfaceFlinger与图形栈4.1 SurfaceFlinger到底在干什么很多驱动工程师会觉得SurfaceFlinger是上面的事和驱动无关。但我想说显示驱动做到后面瓶颈几乎都在这一层。SurfaceFlinger是Android图形系统的中枢它负责接收所有App绘制的Surface图层对这些图层做Z-order排序和可见区域计算调用HWC来合成最终的帧管理每个Surface的生命周期和帧队列。你可以把SurfaceFlinger理解成一个导演它不管演员怎么化妆app怎么绘制只管把所有的镜头按剧本合成好交给放映室HWC去放映。理解这一点你再回头去看驱动层就会明白为什么HWC的接口设计成那样——因为SurfaceFlinger需要精准控制每一层的合成路径和时序。4.2 BufferQueue生产者-消费者模型在Android里App往Surface上画画其实是通过BufferQueue和SurfaceFlinger交互。BufferQueue是一个典型的生产者-消费者队列生产者Producer是App侧的Surface它通过EGL或者Vulkan渲染后把buffer dequeue、render、queue消费者Consumer是SurfaceFlinger侧的BufferQueue消费者它把buffer取出来交给HWC合成。BufferQueue里通常有3个buffer对应三缓冲机制。三缓冲的意义在于即使App渲染耗时超过一个VSYNC下一个buffer已经准备好避免GPU和显示硬件互相等待而出现空档。理解三缓冲是优化掉帧的必经之路。很多显示卡顿问题根子不在驱动而是BufferQueue里的buffer不够用或者dequeue阻塞太久。4.3 VSYNC是整个图形系统的脉搏显示硬件每刷新一帧会产生一个垂直同步信号VSYNC。Android用VSYNC来驱动App渲染和SurfaceFlinger合成确保节奏一致。主VSYNC给App用SF VSYNC给SurfaceFlinger合成用。如果显示驱动的时序不对VSYNC的频率或相位就会乱表现出来就是App掉帧、触摸延迟、动画卡顿。这时候别只盯SurfaceFlinger去内核里查CRTC的mode是不是和panel要求一致DRM有没有正确上报vblank尤其重要。我遇到过不止一次上层怎么优化都掉帧最后发现是panel的refresh rate设成了60Hz但实际屏是90HzVSYNC一直被硬件拉着走节奏全乱了。4.4 怎么用systrace/Perfetto定位掉帧掉帧是所有显示问题里最让人抓狂的。我的标准操作流程是先用systrace抓一次带帧信息的长tracesystrace.py gfx view wm input res am sched freq idle 10 -o trace.html然后在trace里看SurfaceFlinger的标记点。如果出现在doComposition之后的时间戳距离VSYNC太远那是SF合成慢如果SF合成正常但最终显示没有按预期发生那要去HWC层看present的耗时长不长如果App的queueBuffer到SF的onFrameAvailable之间有明显gap那多半是BufferQueue的空闲buffer不足或App的渲染管线Barrier太多。如果你用的Android版本比较新Perfetto更好用能同时看到内核调度、GPU渲染和SF合成事件。推荐先用systrace练手再切Perfetto因为systrace里有些术语在Perfetto里名字变了但概念完全一样。4.5 dumpsys命令的实际观测我在调显示问题时常看这几个输出dumpsys SurfaceFlinger dumpsys SurfaceFlinger --latency dumpsys display | grep -i hwcdumpsys SurfaceFlinger输出里能看到当前Layer的Z序、buffer状态、合成类型。--latency能看到最近128帧的present时间戳配合正态分布的P50/P95能很快速判断是固定掉帧还是随机抖动。顺便说一句很多自带主题或者动态壁纸会常年保持多个图层导致GPU和HWC压力巨大。排查性能问题时先把动态壁纸关掉、把开发者选项里的显示屏幕刷新率打开是基本功。5. 学习路线图与实战练手项目5.1 四阶段路线图我按我自己的经验给出一个可以执行的路线图。阶段目标建议时长核心产出阶段一建立显示子系统全景图1周能画出数据流图并标注关键结构体阶段二掌握内核DRM/KMS驱动4-8周能用modetest点亮屏幕能改panel驱动阶段三掌握HAL层HWC4-8周能对接/调试drm_hwcomposer理解validate/present阶段四掌握SurfaceFlinger与性能调优8-12周能用systrace定位并解决掉帧问题这个时间线对全职学习是合理的如果是业余时间学习至少把阶段一和阶段二压到2个月内完成不然后面很容易放弃。别贪多每一阶段都跟着练手项目走一遍再进下一阶段。5.2 前期必做手写一个DRM实验工具买一块带主控的开发板比如全志、瑞芯微、高通平台的先不接Android直接在Linux下用C写一个DRM测试程序。这个实验要完成四步用drmOpen打开/dev/dri/card0用drmModeGetResources获取CRTC/Encoder/Connector用drmModeSetCrtc把一块Framebuffer铺到Connector上mmap这块Framebuffer往里面画渐变图形。当你把这四步走通你对KMS的整个对象模型就有了肌肉记忆。这也是为什么很多老工程师找工作面试时会被要求在十分钟内写出modetest的简化版——因为它真的是DRM的Hello World。5.3 进阶必做在自己的平台启用drm_hwcomposer当你手头的板子能在Linux下用modetest亮屏后下一步就是进入Android图形栈。先在AOSP里配置好硬件设备的HAL把drm_hwcomposer编进去然后静下心来追踪一帧从SurfaceFlinger到HWC到DRM atomic commit的完整日志。在这个过程中你会遇到三个大的难点Gralloc buffer分配要理解DMA-BUF的fd怎么在进程间传递以及Stride如何计算VSYNC信号怎么从DRM的vblank事件传到HWC再传到SurfaceFlinger多Display时两个屏幕的频率不一致合成器怎么调度。把这三个难点都啃下来你可以说Hello Android显示已经毕业了。5.4 深化学习建议与资料我不会给你一份很大的书单核心就三份干货。Linux内核自带文档Documentation/gpu/drm-kms.rst新版叫drm-kms.rst这份文档虽然更新慢但架构画得很稳必须通读。AOSP源码frameworks/native/libs/gui/BufferQueue*、frameworks/native/services/surfaceflinger、hardware/libhardware/modules/hwcomposer/hwcomposer.cpp这几份文件已经把最难的逻辑写到位。drm_hwcomposer项目源码直接跟着Planner类读一遍合成决策代码比看任何文档都管用。市面上还有一些书比如《深入理解Android内核设计思想》《Android系统多媒体进阶实战》这类能帮你补全图形栈和多媒体部分但核心还是读源码加动手实验别指望看书学会驱动。6. 常见问题与避坑实录6.1 黑屏问题的排查层次黑屏的锅可能在背光、在内核panel、在HWC、在SurfaceFlinger一层层剥。我的排查顺序是先看背光确认GPIO/PWM使能看看屏幕有没有微弱的亮光如果连背光都没有先修背光再看内核dmesg看panel是否注册成功modetest输出是否正常/sys/kernel/debug/dri/0/state有没有报错再看HWCdumpsys display和SurfaceFlinger确认当前有没有HWC layer存在最后看SurfaceFlinger确认BufferQueue里的buffer是否流动起来。这张速查表可以打印出来贴在工位上现象优先排查点核心命令完全无背光背光GPIO/PWMgpioset / cat backlight有背光但无画面panel使能、时序、lane配置dmesg, modetest开机logo正常但Android黑屏HWC/SF合成路径dumpsys SurfaceFlinger亮屏后几秒黑屏ESD检测、休眠流程dmesg, logcat概率性黑屏上电时序、reset时序示波器量时序6.2 花屏和画面撕裂花屏的原因通常与字节序、stride、像素格式有关。比如panel是RGB8888但GPU给的是RGB565或者stride没有按16字节对齐都会导致颜色错乱或者斜向条纹。解决方法很简单确认bpp和stride一致确认DMA-BUF的offset和plane offset一致。画面撕裂多半是没开VSYNC同步或者打开了但没做vblank等待。用DRM atomic模式提交时一定要在atomic_commit里带上event并等vblank事件再更新下一帧否则就会出现上半帧旧、下半帧新的情况。也可以用Page Flip的AUTO模式来让内核自动处理。6.3 掉帧与卡顿的定位口诀掉帧问题我建议每一个调显示的人记一个最简单的口诀先看SF再看HWC最后查buffer。具体来说如果SF的合成耗时正常但帧率起不来去看HWC到present的过程如果HWC正常但帧率依然起不来去看Gralloc和BufferQueue的buffer申请/释放是否阻塞如果以上都正常这叫玄学卡顿去检查CPU频率、GPU频率、内存带宽这些资源竞争。掉帧问题通常不是单点原因所以记录每次验证的时间戳非常重要。我习惯在代码里加printf级别的时间戳把每次queueBuffer、onFrameAvailable、validate、present都打出来再用脚本做时间差分析比纯看systrace更快定位。6.4 独家小技巧如何逼问出一个显示问题最后分享一个我带队时反复用的方法把问题复现降维。只要屏幕出问题第一时间抓dumpsys和logcat复现一次记录时间戳然后把问题降维把多个图层合成问题简化成一个图层把动态界面简化为静态图片。一旦能把问题缩小到某一层某一个操作再下手改代码效率会高十倍。这招看起来简单但真的能省下大量无头绪的调试时间。踩过这么多坑之后我最大的感受是显示驱动看似是驱动实际上你至少要懂一半图形栈才能在问题发生时快速判断到底是内核的时序错了、HWC的规划错了还是SurfaceFlinger的合成节奏出了问题。如果你只是照着datasheet调亮一块屏那不叫会显示驱动真正会的人能从panel初始化一直侃到BufferQueue的buffer流转再顺着一个VSYNC信号把每一层的职责讲清楚。我建议每个想把这条路线走完的人都在纸上画一张自己的数据流图每学一层就往上填结构体和接口最后你手里就是一份比自己简历还值钱的知识地图。等你能看着一张掉帧记录三分钟内定位到是哪一层掉了链子你就算是真正从0到1走通了Android显示驱动这条路。