GPU内核驱动显示子系统集成：从对象模型到调试实战

做GPU内核驱动开发的朋友应该都有过这种经历：insmod之后，dmesg干干净净，硬件初始化也报了成功，内存管理那一套全跑通了，结果接上显示器就是黑屏。花屏、撕裂、分辨率切不过去、热插拔没反应……这些问题追到最后，十有八九都落在显示子系统这个模块上。可见KMD里最难啃、最容易翻车、也最让用户有感知的部分，就是显示这一块。前面专栏里我们聊过KMD的整体框架、内存管理、命令提交等基础主题，这篇4.1专门把显示子系统集成拿出来拆开讲。读完之后，你会对KMD里显示子系统的职责边界、核心对象模型、从驱动加载到画面输出的完整链路，以及调试显示问题时的思路和工具链有一个系统的认知。

这篇内容面向两类人：一类是刚转入GPU驱动开发、想系统搞懂KMD显示模块的新人；另一类是在做桌面显卡、SoC显示控制器适配、或者跑虚拟显示设备方案，被显示问题折磨过的工程师。无论你是从Linux DRM/KMS入手，还是看Windows WDDM的DIsplay模型，这篇文章的核心思路都通用——先搞懂对象关系，再谈寄存器操作。

1. 显示子系统在整个KMD中的定位：为什么它是驱动开发的"面子工程"

1.1 从图形栈全景看KMD显示模块的位置

要理解显示子系统集成，先得看清楚它在整个图形软件栈里的位置。一套完整的GPU驱动体系，从上层往下大致是这样：应用层通过OpenGL/Vulkan/DX12等图形API发起绘制指令，这些指令进入用户态驱动（UMD）后，被翻译成硬件能理解的命令缓冲区，然后通过系统调用进入内核态。在内核态里，KMD负责三件大事：内存管理（显存分配、显存映射）、命令提交（把用户态提交的command buffer调度到GPU执行）、以及显示控制（管理扫描输出、模式设置、VSync等）。

这三件事里，内存和命令提交是“后台工作”，跑得再快用户也感知不到细节；但显示子系统是直接对着人的眼睛输出的。桌面分辨率切不动、视频画面撕裂、显示器休眠后唤不醒，这些全是显示模块的锅。所以我一直跟组里新人说：显示子系统是KMD的“面子工程”，它不一定是技术上最难的，但一定是最容易让用户骂娘的。

1.2 显示子系统到底管哪些事

具体来说，KMD里的显示子系统承担着四类核心职责：

• 模式设置（Mode Setting）：枚举显示器支持的分辨率、刷新率，选择一个模式和显示时序写入显示控制器寄存器，让显示控制器按这个时序去扫描显存。
• 扫描输出管理（Scanout）：决定显存里的哪块区域（Framebuffer）被送到显示器上。这涉及plane（图层）的概念——一个显示管线里可以有多个图层叠加，比如桌面背景是一层、视频窗口是一层、鼠标光标又是一层。
• VSync与vblank管理：显示控制器每扫完一帧，会有一个短暂的消隐期（vblank），KMD要在这个窗口里安全地切换Framebuffer，否则就会出现画面撕裂。vblank还同时是垂直同步、帧率控制、以及合成器（compositor）做画面更新的节拍器。
• 显示器的热插拔与电源联动：检测HDMI/DP线插拔、读取EDID（显示器的“身份证”）、响应系统休眠唤醒，在suspend/resume过程中保存和恢复显示状态。

这里特别要提醒的是：很多刚入行的朋友会把“显示子系统”等同于“点亮屏幕”。点亮屏幕只是其中最小的一个环节，真正的复杂度在于管道（pipeline）的状态管理——什么时候该扫描哪个buffer、切换buffer时硬件处于什么状态、CRTC和Encoder的时钟如何匹配，这些才是集成的难点。

1.3 两种主流的显示架构流派

当前业界主流的KMD显示架构有两大流派，一个是Windows上的WDDM（Windows Display Driver Model），另一个是Linux生态的DRM/KMS（Direct Rendering Manager / Kernel Mode Setting）。

WDDM的逻辑是“GPU是外设，OS是主人”——显示模式、显存调度由OS全局协调，驱动只负责执行；DRM/KMS的逻辑则是“内核是管家”——模式设置的决策权在KMD驱动本身，用户态通过标准接口请求切换，驱动自己判断能不能切、怎么切。从开发者的角度看，DRM/KMS更开放、更容易从零构建一个显示路径，而且大量参考实现（比如vkms、i915、msm）可以借鉴。我下面的内容也以DRM/KMS为主线展开，但里面关于对象关系、时序约束、调试思路的部分，换到WDDM同样适用。

2. 从Framebuffer到Connector：KMD显示对象模型全景拆解

2.1 五个核心对象：显示管线的“积木”

DRM/KMS的显示模型是一套非常优雅的对象拓扑，核心对象就五个：Framebuffer、Plane、CRTC、Encoder、Connector，再加上一个可选的Bridge。把这五个对象串起来，就是一条完整的显示管线。

我用个生活化的类比来帮助理解。想象你家里有一套家庭影院：

• Framebuffer就是画面源本身——一张存在显存里的位图，相当于一部蓝光碟。
• Plane是播放层，它决定这张碟的画面从哪个区域、以什么缩放比例输出；相当于播放器里“画中画”的窗口。一个CRTC下可以挂多个Plane，它们按Z序叠加，最后合成一帧。
• CRTC是显示控制器核心，负责按时序逐行扫描、把合成好的画面变成像素流；相当于投影机的光机，决定了分辨率和刷新率怎么扫。
• Encoder把像素流转成物理信号，比如HDMI编码器把RGB信号转成TMDS差分信号；相当于把播放器的信号转换成HDMI线缆里能跑的格式。
• Connector是物理接口，它代表一个实际存在的输出口（HDMI口、DP口、VGA口），连接着显示器；相当于电视背后的HDMI母座。每个Connector对应一台物理显示器，DP口还可以通过daisy chain挂多个显示器，那是进阶话题。

在这条链路上，数据流的方向是：Framebuffer -> Plane -> CRTC -> Encoder -> Connector -> 显示器。内核在枚举显示资源时，就是把这五个对象的ID和彼此的连接关系暴露给用户态，用户态拿到这些信息后，通过atomic commit来设置链条上每个环节的状态。

2.2 显示管线的拓扑结构与热插拔语义

一条物理显示管线通常是：一个CRTC对应一个Encoder，一个Encoder对应一个Connector。但现代硬件为了灵活性，引入了交叉连接（crossbar）的概念——物理上有两个CRTC、两个Connector，它们之间可以通过内部的交叉开关互联，任意一个CRTC可以选择输出到任意一个Connector。

KMS模型里用possible_crtcs掩码和possible_clones来表达这种可能性：每个Encoder上有一个位掩码，标出它可以配合哪些CRTC工作；Connector上也有一个掩码标出它可以接哪些Encoder。驱动注册这些对象时，必须把掩码填对，否则用户态在选择管线时会被内核直接拒绝。

这里有个新手经常忽略的细节：标准的KMS枚举会为每个Connector建立起一个“当前可能模式列表”（modes list），这个列表的来源有两部分，一是从EDID里解析出来的显示器原生支持的模式，二是驱动用drm_mode_probed_add补充的驱动自定义模式。如果驱动在connector->get_modes回调里没把EDID解析出来的模式正确挂到connector上，用户态用modetest看到的模式列表就是空的，显示器自然点不亮。这个锅经常甩给“硬件问题”，其实根子在对象注册不完整。

2.3 原子状态：把整条管线当作一个事务

KMS对象不只是静态的数据节点，它们的绑定关系是随状态变化的。传统的legacy modeset是逐对象设置，容易踩到中间状态；现代KMS引入了atomic API，要求把整条显示管线的状态作为一个事务来提交。

在atomic模型下，每个核心对象都有一个对应的state对象：drm_plane_state、drm_crtc_state、drm_connector_state。一次atomic commit由用户态发起，内核会经历两个阶段：

• check阶段：内核拿到用户态提交的一组新state，逐项做校验——CRTC和Encoder的兼容性、时钟约束、Framebuffer格式与Plane能力的匹配等。这一步不写任何寄存器，只是“纸上谈兵”。
• commit阶段：check通过之后，才把新state写入硬件寄存器，并在vblank窗口里完成切换。

理解这个两阶段模型，对调试显示问题非常重要。我看到过很多人在调显示驱动时，上来就盯寄存器、抓波形，却忽略了atomic check阶段的校验逻辑。比如在atomic_check里忘了调用drm_atomic_helper_check_modeset，导致模式切换时新的时钟没传到底层，最后现象就是“模式参数变了，但屏幕还是没有按新分辨率工作”。这种问题不看state对象根本定位不到。

3. 实战起步：让一块虚拟显示控制器从加载到点亮

3.1 为什么用虚拟设备做教学

学显示子系统集成，最大的拦路虎是硬件。真GPU有几百页的寄存器手册，不同平台的显示控制器行为差异巨大，而且调试时稍有不慎就可能点不亮屏、甚至把显示器烧了（虽然概率低，但并非没有）。所以我的建议是先用虚拟设备跑通KMS的完整路径，再用真硬件去验证。

这里我选择参考Linux内核自带的vkms（Virtual Kernel Mode Setting）驱动思路，自己写一个最小化的虚拟显示控制器驱动。它的好处是：

• 不需要真实硬件，任何一台能跑Linux内核的机器都能练习；
• 没有硬件寄存器，所有“寄存器操作”都变成内存写操作，逻辑更清晰；
• 可以完整走一遍DRM设备注册、CRTC初始化、模式设置、vblank模拟、Framebuffer扫描输出等核心流程。

3.2 最小虚拟显示控制器的设计目标

我们的目标设定为：一块虚拟显示控制器，支持两个模式（1920x1080@60、1280x720@60），一个CRTC、一个Plane、一个Encoder、一个Connector，输出类型模拟HDMI，Framebuffer格式支持XRGB8888。扫描输出时，我们把显存里的数据直接拷贝到一块模拟的“屏幕内存”里，同时在vblank事件里打点，让用户态能感受到帧率节奏。

为什么选这两个模式？因为它们是驱动调试时最常用的两个基准——1080p验证高分辨率下的时序计算，720p验证模式切换是否干净利落。设计的核心是让代码足够简单，突出主线，不追求多Plane、多CRTC，那些是进阶作业。

3.3 从platform_driver到DRM设备的注册流程

整个驱动采用platform_driver框架，因为虚拟设备不需要PCIe枚举。加载流程分两步：先用platform_device_register_simple注册一个虚拟platform设备，再在驱动的probe函数里完成DRM初始化。

核心注册顺序可以简化成下面这段骨架（为了突出重点，我省略了错误处理细节）：

static int vkms_display_probe(struct platform_device *pdev) { struct drm_device *dev; struct vkms_drm_private *priv; int ret; /* 1. 分配DRM设备 */ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); dev = drm_dev_alloc(&vkms_drm_driver, &pdev->dev); /* 2. 初始化核心对象：CRTC、Plane、Encoder、Connector */ ret = vkms_output_init(dev, &priv->output); /* 3. 注册DRM设备，开始对外暴露 */ ret = drm_dev_register(dev, 0); /* 4. 安装热插拔轮询 */ drm_kms_helper_poll_init(dev); return 0; }

这个顺序有讲究。drm_dev_alloc和drm_dev_register之间，一定要完成所有核心对象的初始化和回调注册，因为设备一旦注册，用户态立刻就能打开设备节点、发起模式查询请求。特别要注意的是drm_dev_register应该在drm_mode_config_init之后，否则设备节点创建了但mode_config还没初始化，用户态一查模式就崩。

3.4 CRTC、Plane、Encoder、Connector逐个初始化

接下来逐个看这些对象的初始化，这是显示子系统集成里最核心的代码。CRTC的初始化重点在回调函数上：

static const struct drm_crtc_funcs vkms_crtc_funcs = { .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, .reset = drm_atomic_helper_crtc_reset, }; static const struct drm_crtc_helper_funcs vkms_crtc_helper_funcs = { .atomic_check = vkms_crtc_atomic_check, .atomic_enable = vkms_crtc_atomic_enable, .atomic_disable = vkms_crtc_atomic_disable, };

注意这里atomic_enable和atomic_disable成对出现，它们对应CRTC的开启和关闭。在真实的显示控制器里，enable时要按照“先配置时序、再输出时钟、最后打开扫描”的顺序操作寄存器；disable时顺序相反——先把扫描关掉，再关时钟，避免在屏幕上出现撕裂的半帧图像。在我们虚拟设备里，就是置一个enabled标志位。

Plane的初始化需要绑定Framebuffer格式支持，核心是drm_plane_create_primary创建主平面，主平面必须支持扫描输出所需的格式（我们这里用DRM_FORMAT_XRGB8888）。Encoder和Connector的初始化相对机械，但有一个细节容易漏：Connector的polled字段要设置DRM_CONNECTOR_POLL_HPD或定期轮询标志，这不仅影响热插拔检测，还决定了modetest能否在启动时枚举到连接器。如果polled=0且没有中断源，Connector会一直停留在“未知连接状态”，用户态看到的connector就是disconnected，所有模式都会被跳过。

3.5 驱动自定义回调里的关键逻辑

完整的模式设置链路里，有三个回调是驱动自定义逻辑的重灾区：mode_valid、atomic_check和atomic_update。我给虚拟设备写的逻辑是这样：

• mode_valid：检查请求的模式是否在我们支持的范围内。比如用户态请求3840x2160，虚拟设备不支持，直接返回MODE_BAD。这个回调里要特别细心处理时钟边界——很多硬件在标称1080p下还有额外的像素时钟限制，如果只查分辨率不查时钟，实机调试时会遇到黑屏。
• atomic_check：不仅要调用helper完成基础校验，还要检查Plane和CRTC的绑定关系、以及Framebuffer尺寸和Plane裁剪区域是否匹配。
• atomic_update：实际把新状态“写到硬件”——虚拟设备里就更新全局状态结构体，真实驱动里则是计算好各个时序参数，按寄存器地址写进去。

模式切换的时序计算值得单独提一句。一个显示模式的三个核心参数是htotal、vtotal和像素时钟clock。像素时钟的计算公式是clock = htotal * vtotal * refresh_rate。比如1920x1080@60，实际的htotal通常是2200（包含水平消隐），vtotal是1125（包含垂直消隐），所以像素时钟大约是2200 * 1125 * 60 = 148.5 MHz。这是HDMI 1080p标准时序，如果驱动里把htotal算错成1920，像素时钟就会算成124.4MHz，真硬件上必然黑屏或者花屏。虚拟设备虽然不校验时钟，但你在做真实驱动时一定要把这份计算做成独立的函数，并配上一个单元测试，这是性价比最高的防错手段。

3.6 用户态验证：用modetest和合成器验证点亮

驱动加载后，怎么验证显示子系统是否工作？先看内核日志确认DRM设备注册成功，然后用libdrm自带的modetest工具验证：

# 查看显示资源：connector、CRTC、plane以及各自的ID modetest -M vkms -p # 强制在connector 32上用CRTC 16输出1080p模式 modetest -M vkms -s 32:1920x1080@60 -d 16 # 跑几秒钟的模式测试，观察vblank计数是否递增 modetest -M vkms -c 4

这里有个验证经验：不要只跑一次modetest -s就认为点亮了。把-c 4连跑几秒，vblank计数如果递增，说明CRTC在稳定扫描输出；如果计数不动，说明CRTC的enable回调没真正生效或者vblank事件没挂上。许多“黑屏”问题，追到根上其实是vblank回调挂了但enable时序不对。

之后再跑一个轻量级合成器（比如weston或者sway）做二次验证。合成器会在初始化时做一整套atomic commit：分配Framebuffer、设置Plane、设置CRTC、触发页面切换。这一整套流程走通，显示子系统的核心才算真正跑起来。跑合成器时如果直接崩溃或报commit失败，优先查内核的atomic_check失败日志——它们通常会在dmesg里给出非常明确的失败原因。

4. 进阶联动：热插拔、电源管理与atomic modeset的关键路径

4.1 热插拔检测：从物理事件到用户态感知

热插拔（Hot Plug Detect，HPD）是显示子系统最典型的异步事件。完整链路是这样的：物理层检测到HDMI线缆电平变化，触发一个硬件中断；KMD在中断处理函数里调用drm_helper_hpd_irq_event，然后内核会重新读取EDID、重建modes列表；最后通过drm_kms_helper_hotplug_event通知用户态，用户态合成器收到事件后重新做资源枚举和模式选择。

在实际代码里，热插拔路径的典型处理是这样：

static irqreturn_t vkms_hpd_irq_handler(int irq, void *arg) { struct drm_device *dev = arg; /* 检测到电平变化后，触发内核重新检查connector状态 */ drm_helper_hpd_irq_event(dev); return IRQ_HANDLED; }

如果硬件没有中断引脚，KMS还提供了轮询机制：在connector->polled里设置DRM_CONNECTOR_POLL_CONNECT和DRM_CONNECTOR_POLL_DISCONNECT，内核会每隔一段时间调用connector->detect查一次连接状态。我用过的几个方案里，轮询机制有个常见坑：轮询间隔（默认10秒）太慢，用户插上显示器后要等十几秒才有反应。所以只要硬件支持中断，优先走中断路径；只有实在没有HPD引脚的老硬件，才考虑轮询，并且建议把轮询周期通过connector->polled的语义校准到2秒级别。

热插拔里最让我头大的坑是EDID缓存一致性。很多驱动为了省时间，会把首次读到的EDID缓存下来，HPD触发后不重新读取，直接返回旧EDID。结果就是：用户拔掉4K显示器、换上一台1080p显示器，系统还认为显示器是4K的，模式列表全是4K，新显示器黑屏。我踩过一次之后，养成了个习惯——HPD中断里强制标记EDID缓存为失效，哪怕成本是多一次I2C读取。这个取舍绝对划算。

4.2 电源管理：suspend/resume期间显示状态怎么保住

系统的休眠唤醒是显示子系统的必考题。suspend过程的推荐顺序是：先停止CRTC扫描（disable）、再关掉Encoder输出、最后保存必要的显示状态（比如当前分辨率、当前Framebuffer地址）。resume过程则相反：先恢复CRTC配置，再恢复Encoder，最后重新enable扫描输出。

电源管理搞不定时最典型的故障是“唤醒后屏幕闪一下但内容全乱了”。这通常是因为resume过程中Framebuffer的地址和内容已经变了——可能GPU的显存在休眠期间掉电了，或者command buffer被回收了。解决思路是resume后强制重新扫描初始Framebuffer，而不是依赖用户态重新提交。我的经验是：suspend时把当前Framebuffer的地址、尺寸、格式存到驱动的私有结构体里，resume时直接把这三个值写回显示控制器寄存器，确保屏幕上第一时间恢复出画面，然后再等用户态合成器接管后续刷新。

还有一个容易忽略的点：有些SoC的显示控制器在休眠时会自动关掉内部时钟域（display clock）。如果你在resume时只恢复了显示控制器的寄存器，但忘了重新打开display clock，屏幕会一直黑着，看起来像是驱动没恢复，其实是时钟门控没解开。排查这类问题最快的方式，是在resume路径里查一下时钟框架的调试信息，确认该开的clock是否有enable_count。

4.3 atomic modeset的两个阶段：check和commit的真实分工

atomic modeset最值得深入理解的是check和commit的分工。我见过不少驱动开发者把校验逻辑全堆在check阶段，导致用户态提交一个明显非法的状态组合时，内核能及时拦截；但有些校验必须等到commit阶段才能做（比如读取硬件当前实际状态）。DRM/KMS的约定是：check只做资源约束和静态参数校验，commit负责与硬件的实际交互。

check阶段要检查的典型项目包括：

• Plane的裁剪区域是否完全落在Framebuffer内；
• CRTC启用的Plane数量是否超过硬件支持的最大图层数；
• 模式切换后像素时钟是否在Encoder支持的范围内；
• Connector和CRTC是否通过可能的拓扑掩码匹配。

我建议至少在check阶段调用drm_atomic_helper_check_modeset和drm_atomic_helper_check_planes这两个helper函数，它们是KMS帮你兜底的核心校验逻辑。很多人图省事只调一个，结果Plane越界、模式冲突的状态没被拦下来，直到硬件出现花屏才回头查，白白浪费大量调试时间。

4.4 多显示头与克隆模式：一条CRTC服务两个Connector

做驱动集成时，另一个绕不开的需求是克隆模式（clone mode）——同一个画面同时输出到两个显示设备，比如会议室的投影仪和电视。KMS里实现克隆的方法是让一个CRTC同时连接到两个Encoder/Connector，用户态做一次modeset，把同样的Framebuffer帧同步到两个输出。

这部分的难点不在KMS对象关系，而在硬件本身：两个Connector的分辨率和时序可能不同，但CRTC只有一个时序发生器，无法同时输出两种分辨率。所以克隆模式有个硬性约束：所有参与克隆的Connector必须工作在相同分辨率和刷新率下。驱动侧能做的最重要一件事，就是在connector->possible_clones掩码里如实填写哪些Connector可以克隆。如果不填，用户态做克隆模式commit时会被内核直接拒绝。我调试过的一个方案是投影仪（1080p）和主显示器（2K），启动克隆模式时投影仪直接无信号，查下来就是possible_clones没配对。

5. 调试工具链与真实翻车现场：踩过的坑一次性说清

5.1 从modetest到DRM debug：显示调试的常规武器

显示子系统调试，工具链很重要。我把平时最常用的工具整理成一张表，按性价比排列：

这里重点说drm_info。很多KMS问题，内核日志里根本没有error级别的报错，只有在atomic check返回-EINVAL时，用户态会收到一个commit失败的返回值，但具体哪一步失败没人告诉你。drm_info会把每个state对象的属性、允许值和当前值打印出来，对照一下就能看出是谁不满足约束。比如Plane的src_w超过了Framebuffer宽度，drm_info里一眼就能看到。

5.2 坑一：模式列表为空导致“显示器点不亮”

症状：modetest -p能看到connector，但connector的modes列表为空，用户态无法选择任何分辨率，屏幕黑屏。根因：驱动在connector->get_modes回调里没有正确调用drm_add_edid_modes，或者EDID读取失败后没给一个兜底模式。排查链路：先看dmesg里EDID读取是否报I2C错误，再用i2cdump确认物理总线能不能读到EDID数据，最后检查get_modes回调是否把读到的数据正确挂到connector->probed_modes上。解决：EDID读取失败时，插入一个驱动内建的兜底模式（比如1024x768@60），保证系统无论如何都能出画面。这个兜底模式在很多真实设备驱动里都有，不是偷懒，是为了避免用户在没有显示器的环境里连桌面都进不去。

5.3 坑二：页面切换时画面撕裂

症状：视频播放或窗口拖动时，屏幕上出现一条水平的撕裂带。根因：Framebuffer切换没有同步到vblank窗口。用户态合成器请求把显示源从A换成B，驱动直接在扫描过程中改了显存地址，导致上半帧来自A、下半帧来自B。排查链路：检查atomic_update回调里有没有drm_crtc_vblank_count配合延迟切换的逻辑；再看vblank中断是否真的被正确配置和使能。解决：硬件层面，扫描输出的起始地址只在vblank期间更新；如果没有这个硬件机制，就在驱动里用drm_crtc_vblank_off期间做切换并在下一个vblank开始前把地址写进去。还要确认一点：atomic_flush里是否调用了drm_crtc_send_vblank_event，如果vblank事件没发出去，用户态合成器会陷入无穷等待，表现为“画面卡死但不一定撕裂”，这个链路很容易忽略。

5.4 坑三：HPD事件触发了但用户态毫无反应

症状：插上显示器，内核日志里能看到[drm] HDMI hot plug event，但桌面就是没反应，不自动切换分辨率。根因：HPD中断只是KMD探测到了物理事件，但通知用户态的drm_kms_helper_hotplug_event没被调用，或者用户态合成器没注册hotplug事件监听。排查链路：先在内核日志里确认HPD触发、drm_helper_hpd_irq_event被调用了；然后在用户态用udevadm monitor查看DRM hotplug uevent是否有发出；都没有问题再看合成器日志。解决：如果内核日志里有HPD但modetest -M <driver>的连接状态还是old，说明connector->detect回调没被重新触发，这时要检查polled标志位是否正确设置——HPD中断触发时，KMS内部需要DRM_CONNECTOR_POLL_HPD来标记这是一个“可被HPD唤醒”的连接器。

5.5 坑四：atomic_commit返回-ENOSPC而不是-EINVAL

症状：分辨率切换或者多显示器扩展时，用户态commit失败，返回-ENOSPC。根因：Plane分配用完了——请求的Plane数超过硬件支持的数量，KMS的atomic check会返回-ENOSPC表示“资源不足”。很多人误以为-ENOSPC只表示磁盘空间不足，在DRM语境下它就是Plane/CRTC资源不够。排查链路：用modetest -p数一下硬件实际支持的Plane数量，以及用户态请求commit时的Plane集合，看有没有重复申请同一个Plane。解决：两种途径，一是优化用户态合成器的图层分配策略，让桌面、视频、光标共享Plane；二是在驱动侧修改drm_crtc_state->plane_mask的校验策略，允许某些场景下用合成器做软叠加，而不是每个窗口都占一个硬件Plane。这个坑在桌面环境下尤其常见，我调试过的某款SoC只有3个Plane，但跑起来同时打开的窗口有四五个，全靠用户态合成器合理调度。

5.6 一个真实案例：RK3288平台上热插拔后EDID不更新

最后分享一个我印象特别深的排查经历。方案是基于RK3288的定制板卡，HDMI输出。现象是：播放器开着视频，拔出HDMI线再插入时，画面不恢复，只有重启合成器才行。一开始怀疑是合成器的问题，但重启合成器后屏幕仍然保持黑屏，这就很反常。

查内核日志，发现HPD事件正常触发，drm_helper_hpd_irq_event被调用了，但再细看vkms/RK平台的connector->get_modes调用路径，发现连接状态被正确更新成connected，但modes列表始终是旧的4K模式列表。实际上新显示器是1080p。问题出在HPD回调里调用了drm_kms_helper_hotplug_event，却没有清理connector->edid缓存，导致get_modes里走的是“有缓存直接复用”的逻辑，压根没触发新的EDID读取。

修复方案是在HPD中断处理函数里，调用drm_connector_update_edid_property之前，强制把connector->edid_blob_ptr置空，并且用drm_add_edid_modes重新探测。这个改动很微小，但解决了大问题。从那以后，我在实现任何显示驱动的HPD路径时，都会先问自己一个问题：这次事件会不会导致EDID变化？如果会，就必须强制重新读取，不能图省事走缓存。显示子系统里这类“缓存一致性”的坑远不止EDID一个，connector状态、modes列表、属性缓存，都可能成为定时炸弹。

我当然也有过深夜对着示波器量像素时钟的经历——那个阶段感觉显示子系统像玄学，怎么调都不亮，第二天白天冷静下来，把state树打出来，几行字就暴露了问题。显示子系统集成的核心其实不是寄存器操作，而是对象关系、状态机、时序约束这些“软件结构”层面的东西。希望这篇4.1能帮你少走一些弯路，在真正动手写显示驱动时，能第一时间把问题定位到正确的地方。