1. 从一块点不亮的LCD说起DRM驱动框架到底在管什么如果你做过嵌入式Linux的LCD屏调试大概率经历过这样的场景设备树配好了时序参数也照着手册填了上电之后屏幕要么全黑要么花屏要么显示几秒就撕裂。这时候翻内核日志看到一串drm开头的报错心里就明白——问题出在DRM驱动框架这一层。LCD DRM驱动框架是Linux内核里负责显示子系统的一套基础设施。它把显示相关的硬件抽象成几个核心概念KMS负责显示管线的配置和管理GEM负责显存缓冲区的分配和生命周期管理。两者配合才能让一块LCD屏从通电走到正确显示画面。这篇文章面向的是正在做LCD驱动开发、或者准备接手显示子系统调试的工程师。我会从框架设计的角度拆解KMS和GEM各自的职责边界然后落到实操层面讲清楚一个LCD驱动从零到能显示画面中间需要打通哪些环节。涉及具体参数计算和代码结构的地方我会给出可以直接参考的写法。需要说明的是不同SoC厂商的DRM驱动实现差异很大我这里讲的是通用框架层面的逻辑具体到某个平台时你需要结合厂商提供的BSP代码来对照理解。但框架层的知识是通用的理解了这一层换平台时上手会快很多。2. KMS机制深度拆解显示管线是怎么被管起来的2.1 KMS的核心抽象对象与职责划分KMS全称Kernel Mode Setting直译过来是内核态显示模式设置。在早期没有KMS的年代显示模式的设置是在用户态做的每次切换分辨率或者刷新画面都要从用户态发起ioctl调用效率低而且容易在切换过程中出现闪烁。KMS把这部分工作收进内核让显示模式的设置和画面更新可以在内核态完成用户态只需要通过标准接口提交帧缓冲即可。KMS把显示硬件抽象成几个对象理解这几个对象之间的关系是理解整个显示管线的关键CRTCCRT Controller代表一个显示控制器负责从显存里读取像素数据按照配置的时序参数输出到显示接口。一个SoC可能有多个CRTC对应多个独立的显示通道。你可以把它理解成一个扫描输出引擎。Encoder编码器负责把CRTC输出的像素信号转换成特定接口协议需要的信号格式。比如MIPI DSI接口、RGB并行接口、LVDS接口各自需要不同的Encoder。Connector连接器代表物理上的显示输出接口比如板子上的FPC排座。它负责探测显示设备是否连接、读取EDID信息如果有的话、维护连接状态。Plane图层代表一个可以独立显示的图像层。一个CRTC可以叠加多个Plane实现硬件图层合成。比如视频层和UI层分别用不同的Plane由硬件完成叠加不需要CPU参与合成。Framebuffer帧缓冲是一块内存区域里面存放着要显示的像素数据。Framebuffer通过GEM对象来管理底层的内存。这几个对象的关系可以这样理解Framebuffer是画布Plane是画布的摆放位置和叠加方式CRTC是把最终画面扫描出去的引擎Encoder是信号转换器Connector是物理出口。用户态通过atomic接口把这一整条链路配置好内核就会在下一个垂直同步周期生效。2.2 显示模式设置从时序参数到CRTC配置LCD屏能正常显示的前提是时序参数正确。时序参数描述了CRTC如何扫描输出一行像素和一场画面。对于RGB接口的LCD关键参数包括参数含义典型值示例800x480屏hactive水平有效像素数800hfront-porch水平前肩40hback-porch水平后肩40hsync-len水平同步脉冲宽度48vactive垂直有效行数480vfront-porch垂直前肩13vback-porch垂直后肩29vsync-len垂直同步脉冲宽度3clock-frequency像素时钟频率Hz33000000这些参数不是随便填的它们决定了CRTC扫描一行需要多少个像素时钟周期以及一场需要多少行。计算方式如下水平总周期 hactive hfront-porch hback-porch hsync-len 垂直总周期 vactive vfront-porch vback-porch vsync-len 实际像素时钟 水平总周期 × 垂直总周期 × 刷新率以800x480屏、60Hz刷新率为例水平总周期 800 40 40 48 928 垂直总周期 480 13 29 3 525 像素时钟 928 × 525 × 60 ≈ 29.2 MHz但实际配置中像素时钟往往要留一些余量因为LCD面板的驱动芯片对时序有一定的容忍范围。如果时钟偏低可能出现画面偏移时钟偏高可能超出面板规格导致显示异常。我一般会在计算值基础上加5%到10%的余量然后实测微调。在设备树里这些参数通常这样配置panel { compatible panel-simple; width-mm 154; height-mm 86; display-timings { timing0 { clock-frequency 33000000; hactive 800; vactive 480; hfront-porch 40; hback-porch 40; hsync-len 48; vfront-porch 13; vback-porch 29; vsync-len 3; hsync-active 0; vsync-active 0; de-active 1; pixelclk-active 0; }; }; };这里有几个容易踩坑的地方。hsync-active和vsync-active表示同步信号的极性0表示低电平有效1表示高电平有效。这个必须和LCD面板手册一致搞反了会导致画面偏移或者完全无法显示。de-active是数据使能信号的极性同样要对照手册。pixelclk-active表示像素时钟的采样边沿0表示下降沿采样1表示上升沿采样。这几个极性参数如果配错现象通常是画面整体偏移、颜色错乱或者完全黑屏。2.3 Atomic模式设置为什么它是现代DRM驱动的标配早期的DRM驱动使用legacy模式设置接口用户态需要分别调用多个ioctl来设置CRTC、Plane、Connector的状态。这种方式的问题是多个ioctl之间不是原子的如果在设置过程中有另一个进程也在操作显示设备就可能出现中间状态导致画面闪烁或者配置冲突。Atomic模式设置把整条显示管线的配置打包成一个原子操作要么全部生效要么全部不生效。用户态通过drmModeAtomicCommit提交一个包含所有变更的请求内核在垂直同步周期统一应用。这样做的好处是不会出现中间状态画面切换干净利落支持测试提交test-only commit可以在真正生效前检查配置是否合法支持非阻塞提交提交后立即返回不会阻塞用户态线程对于LCD驱动开发者来说Atomic模式意味着你需要实现atomic_begin、atomic_flush、atomic_enable、atomic_disable等回调函数。其中atomic_flush是最关键的它负责把用户态提交的Plane配置写入硬件寄存器。这个函数的执行时机是在垂直同步期间所以不能做耗时操作否则会导致画面撕裂。我见过不少驱动在atomic_flush里做大量的寄存器读写结果导致帧率上不去。正确的做法是把配置计算提前做好atomic_flush里只做必要的寄存器写入。如果硬件支持Shadow Register影子寄存器那就更好了——在非同步期间写入影子寄存器垂直同步时硬件自动切换CPU几乎不参与。2.4 竖屏改横屏旋转背后的KMS处理逻辑热词里提到了mipi dsi drm竖屏改横屏显示这是LCD驱动调试中非常常见的一个需求。很多LCD面板原生是竖屏的但产品需要横屏显示。这时候有两种做法第一种是在用户态做旋转通过GPU或者CPU把画面旋转90度后再提交给DRM。这种做法的好处是不需要改驱动缺点是增加了GPU/CPU负载而且旋转后的画面可能有锯齿。第二种是在KMS层做旋转利用硬件的旋转功能。如果显示控制器支持硬件旋转可以在Plane的配置里设置rotation属性为DRM_MODE_ROTATE_90。内核在扫描输出时会自动按旋转后的坐标读取像素数据。这种做法的好处是零额外开销缺点是并非所有硬件都支持。如果硬件不支持旋转还有一种折中方案在驱动里修改时序参数把hactive和vactive对调同时调整porch参数。但这要求LCD面板本身支持横屏扫描模式否则显示内容会错乱。我实测下来大部分MIPI DSI面板是不支持这种做法的还是得靠硬件旋转或者GPU旋转。在设备树里旋转通常这样配置display-engine { compatible vendor,display-engine; ports { port0 { reg 0; display_out: endpoint { remote-endpoint panel_in; rotation 90; }; }; }; };但要注意rotation属性是否生效取决于驱动实现。有些厂商的驱动根本不解析这个属性你配了也没用。这种情况下只能在用户态用GPU做旋转或者找厂商要支持旋转的驱动版本。3. GEM机制全解析显存缓冲区是怎么被管起来的3.1 GEM对象的创建与生命周期GEM全称Graphics Execution Manager最初是为GPU显存管理设计的后来被DRM框架采用作为通用的图形缓冲区管理机制。GEM的核心是drm_gem_object结构体它代表一块可以被GPU、显示控制器、CPU访问的内存区域。创建一个GEM对象通常有两种方式dumb buffer通过DRM_IOCTL_MODE_CREATE_DUMB创建适合简单的帧缓冲不支持GPU加速。内核会自动分配一块连续的物理内存并返回一个handle。GEM buffer object通过驱动自定义的ioctl创建可以支持更复杂的内存布局比如tiled格式、压缩格式等。GPU可以直接渲染到这种缓冲区。对于LCD显示来说如果只是显示静态画面或者简单的UIdumb buffer就够用了。但如果要做视频播放或者3D渲染就需要用GEM buffer object让GPU渲染完直接交给显示控制器扫描输出避免内存拷贝。GEM对象的生命周期管理依赖引用计数。当用户态打开一个GEM handle时引用计数加一关闭handle时引用计数减一。当引用计数归零时GEM对象被销毁内存被释放。这个机制保证了缓冲区不会在还被使用时被意外释放。但这里有一个经典的坑GEM handle是进程私有的。进程A创建的GEM对象进程B无法直接通过handle访问。如果要做跨进程共享需要通过DRM_IOCTL_PRIME_HANDLE_TO_FD把handle转换成文件描述符然后通过Unix域套接字传递给另一个进程另一个进程再用DRM_IOCTL_PRIME_FD_TO_HANDLE转换回handle。这套机制叫PRIME是实现零拷贝显示的关键。3.2 CMA与IOMMUGEM内存分配背后的两种路径GEM对象的内存从哪里来这是驱动开发者必须搞清楚的问题。在嵌入式Linux里显示缓冲区的内存分配通常有两种路径CMAContiguous Memory Allocator从预留的连续内存区域分配。优点是物理地址连续显示控制器可以直接使用不需要IOMMU参与。缺点是预留的内存区域大小固定如果预留太小大分辨率或者多图层场景下可能分配失败预留太大又浪费内存。IOMMU/SMMU通过IOMMU把分散的物理页面映射成连续的设备地址。优点是内存利用率高不需要预留大块连续内存。缺点是需要硬件支持IOMMU而且IOMMU的页表维护有一定的开销。在实际项目中怎么选我的经验是如果SoC支持IOMMU优先用IOMMU方案内存利用率高而且支持动态分配。如果SoC不支持IOMMU那就只能用CMA这时候需要根据最大分辨率和使用场景来估算预留大小。估算CMA预留大小的公式单缓冲区大小 宽度 × 高度 × 每像素字节数 总需求 单缓冲区大小 × 缓冲区数量 × 图层数量以1920x1080、ARGB88884字节/像素为例单缓冲区 1920 × 1080 × 4 8,294,400 字节 ≈ 7.9 MB 双缓冲 7.9 × 2 15.8 MB 如果支持3个图层 15.8 × 3 47.4 MB这还没算上GPU渲染需要的额外缓冲区。所以CMA预留通常要给到64MB到128MB具体看产品需求。我见过有项目因为CMA预留只有32MB结果播放4K视频时分配失败画面直接黑屏。3.3 Framebuffer与GEM的绑定关系Framebuffer是用户态看到的画布GEM是底层的内存管理对象。一个Framebuffer可以绑定一个或多个GEM对象多平面格式时比如YUV420Y、U、V分量分别在不同的GEM对象里。创建Framebuffer的流程通常是创建GEM对象得到handle通过DRM_IOCTL_MODE_ADDFB2创建Framebuffer传入GEM handle、像素格式、宽高、pitch等信息得到Framebuffer ID在Atomic提交时把Framebuffer ID设置到Plane的FB_ID属性上这里的关键参数是pitch也叫stride表示一行像素占用的字节数。pitch不一定等于宽度乘以每像素字节数因为硬件可能要求pitch对齐到特定边界比如64字节或256字节。如果pitch设置错误画面会出现斜纹或者错位。计算pitch的示例// 假设宽度1920ARGB8888格式每像素4字节 int width 1920; int bpp 32; int pitch width * bpp / 8; // 7680 // 如果硬件要求pitch对齐到256字节 pitch (pitch 255) ~255; // 7680已经对齐如果宽度是1366ARGB8888int pitch 1366 * 4; // 5464 pitch (pitch 255) ~255; // 5632这时候pitch比实际需要的多出168字节这些填充字节不会被显示但内存分配时必须算进去。3.4 显存同步与Cache一致性处理这是LCD驱动调试中最容易出问题的地方之一。当CPU写入帧缓冲数据后数据可能还在CPU Cache里没有真正写到DDR。如果这时候显示控制器去读DDR读到的就是旧数据画面上就会出现残影或者花屏。解决这个问题有两种方式非一致性映射Non-coherent mapping在CPU写入后显式调用dma_sync_single_for_device把Cache刷到DDR。在显示控制器读完之前不能再让CPU写这块内存。这种方式的优点是内存访问效率高缺点是需要手动管理同步容易漏掉。一致性映射Coherent mapping分配内存时就标记为一致性内存CPU和设备的访问由硬件保证一致。优点是编程简单不需要手动同步。缺点是CPU访问速度可能慢一些因为要走uncached路径。在GEM驱动里通常用dma_alloc_attrs来分配内存通过DMA_ATTR_NON_CONSISTENT标志来决定是否使用一致性映射。对于显示缓冲区我一般推荐用非一致性映射加手动同步因为显示缓冲区的写入通常是大块的手动同步一次比每次访问都走uncached路径要快。同步的代码示例// CPU写入数据后刷Cache dma_sync_single_for_device(dev, gem_obj-dma_addr, gem_obj-size, DMA_TO_DEVICE); // 显示控制器读完后如果CPU要重新写需要invalidate dma_sync_single_for_cpu(dev, gem_obj-dma_addr, gem_obj-size, DMA_FROM_DEVICE);注意DMA_TO_DEVICE和DMA_FROM_DEVICE的方向。对于显示缓冲区CPU是写入方设备是读取方所以CPU写完刷Cache用DMA_TO_DEVICE。如果CPU要读回显示内容比如截图那就要用DMA_FROM_DEVICE先invalidate Cache确保读到的是DDR里的最新数据。4. 从零搭建一个LCD DRM驱动实操流程与关键代码4.1 驱动初始化注册DRM设备与KMS对象一个LCD DRM驱动的初始化流程大致如下分配drm_device结构体初始化GEM驱动设置drm_driver的gem_create_object等回调初始化KMS驱动创建CRTC、Plane、Encoder、Connector注册DRM设备创建设备节点/dev/dri/card0加载LCD面板驱动建立Connector和Panel的连接代码骨架static int lcd_drm_probe(struct platform_device *pdev) { struct lcd_drm_private *priv; struct drm_device *drm; int ret; priv devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; drm drm_dev_alloc(lcd_drm_driver, pdev-dev); if (IS_ERR(drm)) return PTR_ERR(drm); priv-drm drm; platform_set_drvdata(pdev, priv); // 初始化GEM ret lcd_gem_init(drm); if (ret) goto err_put; // 初始化KMS ret lcd_kms_init(drm); if (ret) goto err_gem; // 注册DRM设备 ret drm_dev_register(drm, 0); if (ret) goto err_kms; return 0; err_kms: lcd_kms_fini(drm); err_gem: lcd_gem_fini(drm); err_put: drm_dev_put(drm); return ret; }这里的关键是初始化顺序GEM要先于KMS初始化因为KMS的Framebuffer创建依赖GEM对象。注册DRM设备要放在最后因为注册之后用户态就可以打开设备节点了这时候所有回调必须已经就绪。4.2 CRTC与Plane的初始化细节CRTC的初始化主要是实现drm_crtc_funcs和drm_crtc_helper_funcs两组回调。前者是用户态调用的接口后者是Atomic提交时内核调用的接口。static const struct drm_crtc_funcs lcd_crtc_funcs { .set_config drm_atomic_helper_set_config, .destroy drm_crtc_cleanup, .reset drm_atomic_helper_crtc_reset, .atomic_duplicate_state drm_atomic_helper_crtc_duplicate_state, .atomic_destroy_state drm_atomic_helper_crtc_destroy_state, }; static const struct drm_crtc_helper_funcs lcd_crtc_helper_funcs { .atomic_check lcd_crtc_atomic_check, .atomic_begin lcd_crtc_atomic_begin, .atomic_flush lcd_crtc_atomic_flush, .atomic_enable lcd_crtc_atomic_enable, .atomic_disable lcd_crtc_atomic_disable, };atomic_check里要做的事情是验证用户态提交的配置是否合法。比如检查分辨率是否超过硬件支持的最大值、像素格式是否支持、Plane数量是否超限等。如果检查不通过返回-EINVAL整个Atomic提交就会失败用户态会收到错误码。atomic_flush是最核心的回调它负责把配置写入硬件。典型的实现是static void lcd_crtc_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { struct lcd_drm_private *priv crtc_to_priv(crtc); struct drm_plane *plane; unsigned long flags; spin_lock_irqsave(priv-reg_lock, flags); // 更新Plane配置 drm_atomic_crtc_for_each_plane(plane, crtc) { lcd_plane_update(plane); } // 触发显示控制器更新 lcd_reg_write(priv, LCD_REG_UPDATE, 1); spin_unlock_irqrestore(priv-reg_lock, flags); }注意这里用了spin_lock_irqsave因为atomic_flush可能在中断上下文里被调用垂直同步中断不能睡眠。所有寄存器操作必须是原子的不能调用可能睡眠的函数。4.3 Connector与Panel的对接Connector负责探测显示设备的连接状态并读取显示模式信息。对于LCD面板通常不需要热插拔探测因为面板是焊在板子上的。但Connector的get_modes回调仍然需要实现用来返回面板支持的显示模式。static int lcd_connector_get_modes(struct drm_connector *connector) { struct lcd_drm_private *priv connector_to_priv(connector); struct drm_display_mode *mode; mode drm_mode_duplicate(connector-dev, priv-panel_mode); if (!mode) return 0; drm_mode_set_name(mode); drm_mode_probed_add(connector, mode); return 1; }priv-panel_mode是从设备树或者Panel驱动里解析出来的时序参数。如果Panel驱动实现了drm_panel接口也可以通过drm_panel_get_modes来获取。Connector的detect回调对于LCD面板通常直接返回connector_status_connected因为面板不会拔掉。但如果你的产品支持外接显示器那就要实现真正的探测逻辑比如读取EDID或者检测HPD信号。4.4 点亮屏幕完整的Atomic提交示例驱动就绪后用户态通过libdrm库来操作显示设备。一个完整的点亮屏幕流程如下// 打开DRM设备 int fd open(/dev/dri/card0, O_RDWR | O_CLOEXEC); // 设置Atomic能力 drmSetClientCap(fd, DRM_CLIENT_CAP_ATOMIC, 1); // 获取显示资源 drmModeRes *res drmModeGetResources(fd); // 选择CRTC和Connector uint32_t crtc_id res-crtcs[0]; uint32_t connector_id res-connectors[0]; // 创建Dumb Buffer struct drm_mode_create_dumb create { .width 800, .height 480, .bpp 32, }; drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, create); // 映射内存 struct drm_mode_map_dumb map { .handle create.handle }; drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, map); void *fb_ptr mmap(0, create.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, map.offset); // 填充画面红色 for (int i 0; i 800 * 480; i) ((uint32_t *)fb_ptr)[i] 0xFFFF0000; // 创建Framebuffer uint32_t fb_id; drmModeAddFB(fd, 800, 480, 24, 32, create.pitch, create.handle, fb_id); // Atomic提交 drmModeAtomicReq *req drmModeAtomicAlloc(); drmModeAtomicAddProperty(req, crtc_id, prop_crtc_active, 1); drmModeAtomicAddProperty(req, crtc_id, prop_crtc_mode_id, mode_id); drmModeAtomicAddProperty(req, connector_id, prop_connector_crtc_id, crtc_id); drmModeAtomicAddProperty(req, plane_id, prop_plane_fb_id, fb_id); drmModeAtomicAddProperty(req, plane_id, prop_plane_crtc_id, crtc_id); drmModeAtomicAddProperty(req, plane_id, prop_plane_src_w, 800 16); drmModeAtomicAddProperty(req, plane_id, prop_plane_src_h, 480 16); drmModeAtomicAddProperty(req, plane_id, prop_plane_crtc_w, 800); drmModeAtomicAddProperty(req, plane_id, prop_plane_crtc_h, 480); drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_ALLOW_MODESET, NULL); drmModeAtomicFree(req);这段代码执行后屏幕上应该显示纯红色。如果显示的是其他颜色或者花屏那就要检查像素格式、pitch、时序参数这几个地方。5. 调试实战常见问题与排查技巧实录5.1 屏幕完全不亮从电源到时钟的排查链路屏幕完全不亮是最常见的问题排查要按顺序来不要跳步电源用万用表量LCD面板的VCC、VDD、AVDD等电源引脚确认电压正常。有些面板需要多个电源域上电顺序也有要求必须对照手册。背光背光是否点亮如果背光没亮屏幕看起来就是全黑的但实际可能已经有画面了。用手电筒照屏幕如果能看到淡淡的图像那就是背光问题。时钟用示波器量像素时钟引脚确认有波形输出。如果没有波形说明CRTC没有正常工作检查CRTC的enable寄存器是否置位。同步信号量HSYNC、VSYNC、DE信号确认时序符合面板手册。如果同步信号极性反了画面会偏移或者完全无法显示。数据信号量RGB数据线确认有数据翻转。如果数据线一直是固定电平说明Plane没有正确配置或者Framebuffer地址不对。我遇到过最隐蔽的一个问题是面板的复位引脚RESET没有正确释放导致面板一直处于复位状态。这个引脚在设备树里配了GPIO但驱动里忘记在probe时拉高。排查了半天才发现是复位时序的问题。5.2 画面花屏或撕裂GEM缓冲区同步问题定位画面花屏通常和GEM缓冲区的同步有关。典型现象是画面显示几帧正常内容后突然出现一帧花屏然后又恢复正常。这种间歇性的花屏十有八九是Cache同步问题。排查方法在CPU写入帧缓冲后加dma_sync_single_for_device确保数据刷到DDR检查是否使用了双缓冲。如果只有一个缓冲区CPU在写的时候显示控制器也在读必然撕裂检查垂直同步中断是否正常触发。如果VSYNC中断丢失Atomic提交可能在不正确的时机生效双缓冲的实现逻辑// 准备两个缓冲区 struct buffer { uint32_t fb_id; void *ptr; uint32_t handle; } bufs[2]; int current_buf 0; // 渲染下一帧到另一个缓冲区 int next_buf 1 - current_buf; render_to_buffer(bufs[next_buf].ptr); // 等待垂直同步后提交 drmModeAtomicAddProperty(req, plane_id, prop_plane_fb_id, bufs[next_buf].fb_id); drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_NONBLOCK, NULL); current_buf next_buf;用DRM_MODE_ATOMIC_NONBLOCK标志可以让提交立即返回不阻塞用户态线程。但要注意非阻塞提交后不能立即修改刚提交的缓冲区否则可能和显示控制器的读取冲突。通常需要等待一个垂直同步周期后再修改。5.3 分辨率切换失败Atomic Check的常见拒绝原因分辨率切换失败时内核日志里通常会有atomic check failed的提示。常见的拒绝原因包括错误原因日志关键词解决方法像素时钟超出范围clock out of range检查CRTC的时钟限制调整时序参数内存带宽不足bandwidth exceeded降低分辨率或减少图层数量Plane格式不支持unsupported format检查Plane支持的格式列表Connector未连接connector not connected检查Panel探测逻辑模式不匹配mode not found确认Panel支持该分辨率我印象最深的一次是切换4K分辨率时一直失败日志显示bandwidth exceeded。后来发现是CMA预留内存不够4K双缓冲需要的内存超过了预留值。把CMA从64MB调到128MB后问题解决。这个问题的隐蔽之处在于它不是在分配时失败而是在Atomic Check阶段就被拒绝了因为内核会预先计算带宽需求。5.4 亮度调节不生效PWM背光与DRM属性的联动LCD亮度调节通常通过PWM控制背光芯片实现。在DRM框架里亮度可以作为一个Connector属性暴露给用户态。实现方式// 在Connector初始化时创建亮度属性 drm_object_attach_property(connector-base, priv-brightness_property, 50); // 属性写入回调 static int lcd_connector_set_property(struct drm_connector *connector, struct drm_connector_state *state, struct drm_property *property, uint64_t val) { struct lcd_drm_private *priv connector_to_priv(connector); if (property priv-brightness_property) { // 把0-100的亮度值映射到PWM占空比 int duty val * priv-pwm_period / 100; pwm_config(priv-pwm, duty, priv-pwm_period); pwm_enable(priv-pwm); } return 0; }用户态通过drmModeObjectSetProperty来设置亮度。但要注意亮度属性是Connector级别的不是CRTC或Plane级别的。有些实现会把亮度放在Panel驱动里通过sysfs节点暴露这样更简单但不够DRM原生。我实测下来PWM频率的选择很关键。频率太低比如100Hz会有肉眼可见的闪烁频率太高比如100kHz可能导致背光芯片响应不过来。一般选1kHz到10kHz之间比较合适。另外PWM的极性也要和背光芯片匹配搞反了会出现亮度值越大越暗的奇怪现象。6. 性能优化与进阶话题6.1 减少内存拷贝PRIME与DMA-BUF的实际应用在视频播放场景中视频解码器输出的帧需要交给显示控制器显示。如果解码器输出到普通内存然后CPU拷贝到GEM缓冲区这个拷贝开销很大。用PRIME/DMA-BUF可以实现零拷贝解码器直接输出到DMA-BUF显示控制器通过PRIME导入这个DMA-BUF作为Framebuffer。流程如下解码器创建DMA-BUF导出文件描述符显示进程通过DRM_IOCTL_PRIME_FD_TO_HANDLE导入DMA-BUF得到GEM handle用这个handle创建Framebuffer提交显示这样整个链路中没有内存拷贝解码器写到哪里显示控制器就从哪里读。但要注意同步问题解码器写完一帧后必须通过DMA-BUF的fence机制通知显示进程显示进程收到fence后才能提交显示。否则可能显示到一半解码器还在写画面就撕裂了。6.2 多图层合成Plane的硬件叠加与性能权衡现代显示控制器通常支持多个Plane可以实现硬件图层叠加。比如视频用一个PlaneUI用另一个Plane硬件自动叠加不需要GPU参与合成。这样做的好处是省电、省带宽。但硬件Plane的数量是有限的通常2到4个。如果图层数量超过硬件Plane数量就需要GPU先合成一部分图层再交给显示控制器。这时候就要权衡是用GPU合成增加功耗还是减少图层数量降低用户体验。我的经验是对于视频播放场景优先保证视频层用硬件PlaneUI层如果数量不多也用硬件Plane如果UI层太多就合并成一个图层再交给硬件。对于游戏场景GPU渲染本来就是必须的合成也交给GPU做显示控制器只需要一个Plane就够了。6.3 低功耗显示PSR与Panel Self RefreshPSRPanel Self Refresh是一种低功耗显示技术。当画面内容没有变化时显示控制器可以停止扫描输出让LCD面板自己刷新面板内部有帧缓冲。这样可以关闭显示控制器的时钟节省功耗。实现PSR需要面板支持而且驱动要正确处理PSR的进入和退出。进入PSR的条件是连续多帧画面没有变化。退出PSR的条件是有新的Framebuffer提交或者有中断事件。PSR的调试比较麻烦因为进入PSR后显示控制器不工作了如果这时候有调试信息要打印可能会卡住。我一般建议在PSR调试阶段先关闭PSR功能等基本显示功能稳定后再开启PSR进行功耗优化。7. 个人实操体会与后续扩展方向做LCD DRM驱动这些年我最大的体会是框架层的知识比具体平台的寄存器操作更重要。寄存器操作换一个平台就要重新学但KMS和GEM的框架逻辑是通用的。理解了CRTC、Plane、Connector、Encoder之间的关系理解了GEM对象的生命周期和同步机制换平台时只需要对照新平台的硬件手册把框架层的回调实现填进去就行。另一个体会是调试显示问题一定要有示波器和万用表。很多问题看日志是看不出来的必须量信号。比如时序参数配错了日志可能没有任何报错但示波器一量就发现HSYNC频率不对。又比如电源问题日志也看不出来万用表一量就知道哪个电源域没上电。后续如果想深入可以研究几个方向一是写一个完整的Panel驱动支持多种分辨率和时序参数通过设备树配置二是研究DRM的Writeback功能把显示内容回写到内存用于截图或者录屏三是研究DRM的Lease机制把显示资源分配给不同的进程使用适合VR/AR场景。这些方向每一个都够写一篇长文后面有机会再展开聊。如果你正在调试LCD驱动遇到KMS或GEM相关的问题欢迎一起交流。踩过的坑多了自然就有经验了。