DRM KMSKernel Mode Setting是 Linux DRM 框架中负责内核态显示模式配置与扫描输出的核心子系统其核心价值在于将显示时序、分辨率、图层合成等关键操作从用户态收归内核统一管理实现启动无闪烁、切屏稳定、用户态无 root 权限操作硬件的目标。KMS 以标准化对象模型抽象显示硬件通过原子提交保证状态一致性构成从内存像素到屏幕画面的完整流水线。核心定位与演进本质DRM 子系统的显示管理模块负责mode setting分辨率 / 刷新率 / 时序、scanout扫描输出、plane composition硬件图层合成。关键演进从传统的用户态模式设置如 Xorg 直接操作硬件升级为内核托管Linux 4.2 后原子 KMSAtomic KMS成为标准解决了传统 API 分步设置导致的闪烁、回滚困难问题。核心优势稳定性内核作为显示状态唯一仲裁者用户态崩溃时可切回文本控制台无缝性内核启动早期即可设置最佳模式消除启动 / 切屏闪烁安全性用户态通过标准ioctl接口操作无需直接访问硬件核心对象模型流水线抽象KMS 将显示硬件抽象为5 个核心对象构成Framebuffer → Plane → CRTC → Encoder → Connector的数据流向辅以 Bridge 适配外部芯片。对象内核结构核心作用关键属性硬件映射Framebufferdrm_framebuffer像素数据容器关联 GEM/TTM 内存宽 / 高、像素格式如 ARGB8888、pitch、GEM 句柄显存缓冲区含物理 / 虚拟地址Planedrm_plane图层合成单元支持裁剪 / 缩放 / 旋转源矩形、目标矩形、z-order、帧率硬件叠加层Primary/Overlay/CursorCRTCdrm_crtc扫描引擎核心负责时序生成与合成显示模式drm_display_mode、active、plane 列表显示控制器Timing GeneratorEncoderdrm_encoder信号格式转换内部辅助对象类型HDMI/DP/LVDS、CRTC 关联编码芯片如 TMDS/DP 编码器Connectordrm_connector物理输出接口负责 EDID 读取连接状态、支持模式列表、Encoder 关联HDMI/DP/LVDS 物理插座Bridgedrm_bridge外部芯片适配可选链路拓扑、信号转换转接芯片、Retimer、Panel 驱动关键对象说明Plane 类型Primary每个 CRTC 必选作为主图层Overlay用于视频 / UI 叠加支持硬件合成Cursor专用硬件光标层降低 CPU 开销 。CRTC 核心决定系统最大独立显示数如 2 个 CRTC 可驱动 2 个独立显示器支持克隆模式一个 CRTC 驱动多个 Connector。Encoder 与 BridgeEncoder 为内部抽象实际信号转换常由 Bridge 实现如 SoC 内置 Encoder 连接外部 DP Bridge。DRM PlanePlane 硬件图层是直接喂给 CRTC 扫描的 “像素源”。没有 PlaneCRTC 就没东西可显示。你可以把它理解成Framebuffer 是画布Plane 是图层通道CRTC 是显示器的眼睛在内核里struct drm_plane { struct drm_crtc *crtc; // 绑定到哪个显示控制器 struct drm_framebuffer *fb; // 绑定的图像缓冲区 unsigned int type; // PRIMARY / OVERLAY / CURSOR ... };Plane 是硬件真正能合成、叠加、缩放、旋转的最小单元。软件合成CPU/GPU 画到一起 费性能硬件合成多 Plane 叠加 零开销、低延迟三种标准 PlaneDRM_PLANE_TYPE_PRIMARY主图层每个 CRTC 至少一个用来显示桌面、UI、主画面必须有否则黑屏DRM_PLANE_TYPE_OVERLAY叠加层视频、摄像头预览、游戏画面专用支持硬件缩放、alpha、旋转、色域转换高性能显示的关键DRM_PLANE_TYPE_CURSOR鼠标光标专用层硬件独立通道不占带宽移动极快不影响主画面Plane 的硬件能力现代显示驱动里Plane 一般支持绑定任意 FB源矩形裁剪src_x/y/w/h目标位置缩放crtc_x/y/w/h旋转 0/90/180/270半透明混合alpha多图层 z-order 叠加直接从 DMA-BUFcamera /decoder取数据 →零拷贝显示这就是为什么视频硬显一定要用 Overlay Plane。数据流水线FB / DMA-BUF ↓ Plane [src → 缩放/旋转/混合] ↓ CRTC [时序生成] ↓ Encoder → Connector → 屏幕原子 KMS 里的 Plane原子提交必须一次性设置FB_IDSRC_X/Y/W/H像素源区域CRTC_X/Y/W/H屏幕目标区域会自动缩放CRTC_ID...典型属性FB_IDCRTC_IDSRC_X,SRC_Y,SRC_W,SRC_HCRTC_X,CRTC_Y,CRTC_W,CRTC_Hrotationalpha内核驱动必须实现struct drm_plane_funcs struct drm_plane_helper_funcs - atomic_check() - atomic_update() - atomic_disable()Plane关键要点内核 / 驱动视角Primary Plane 不是软件层是硬件层。Overlay Plane 才是高性能视频 / 相机通道。一个 CRTC 可以绑N 个 Plane看硬件。所有图层最终由硬件合成器Compositor混合。不使用 Plane → 只能软件合成 → 高 CPU、高延迟。驱动里注册 Plane声明支持格式RGB、NV12、NV24…实现 atomic 回调配置通道、Z 序、混合显示控制器显示控制器 显示的 “心脏 时序发生器”Plane 控制器内部的 “图层输入通道”没有显示控制器屏幕就没有时序、没有刷新、没有同步。没有Plane控制器没有图像可显示。一个 Plane 只能绑定到一个控制器CRTC一个控制器可以同时绑定多个 Plane多图层控制器不绑定 Plane 黑屏先统一名词内核 / 硬件对应软件概念DRM/KMS硬件叫法各家 SoC作用CRTCVOPRockchip、DC高通 / 海思、Display Engine、DISP显示控制器PlaneLayer、Win、Channel、Video Layer图层通道现代显示控制器内部硬件结构一定是这样核心关系Plane 是显示控制器的内部资源从属关系一个控制器 带 N 个 PlanePlane 不能脱离控制器单独存在控制器负责 “什么时候显示”分辨率、刷新率、时钟、vblank、同步Plane 负责 “显示什么内容、从哪块内存来”源地址、裁剪、缩放、旋转、格式最终显示 控制器时序 N 个 Plane 硬件合成核心要点Plane 数量是控制器决定的不是 DRM 框架给的是硬件死的。不同控制器的 Plane 不能混用比如 VOP Big 的图层不能给 VOP Little。视频硬显必须走控制器的 Overlay Plane走 Primary 软合成 CPU 爆炸。旋转、缩放、NV12 都是 Plane 能力不是控制器能力驱动上报drm_plane_cap。主流显示控制器海思 Hi3559AV100/Hi3519AV100安防 / 车载 SoCPlane 配置多 VO/VI 通道联动支持 1 Primary 4 Overlay 1 Cursor硬件 WDR、OSD 叠加、视频解码零拷贝入 Plane适用高端运动相机、AR-HUD、多目监控瑞芯微 RK3588VOP2 显示引擎Plane 配置每 VOP 支持 1 Primary 多个 Overlay 1 Cursor多 VOP 可组合出 8 图层支持 AFBC 压缩、旋转 0/90/180/270、alpha 混合、4K60 多图层实时合成典型输出HDMI 2.1 8K60、DP 1.4多屏异显适用8K 机顶盒、车载四屏、运动相机 4K 预览 UI 叠加全志 H618/V853低成本嵌入式Plane 配置1 Primary 2 Overlay 1 Cursor支持 1080p 硬件缩放、alpha适用入门级行车记录仪、便携显示器、IoT 屏AMD RDNA2/RDNA3GPU 显示引擎Plane 配置每个 CRTC 1 Primary 3 Overlay支持 FreeSync、HDR、硬件旋转Linux amdgpu 驱动完整支持原子 KMS适用Linux 桌面、专业显示工作站英特尔 Xe 核显i9-14900H 等Plane 配置1 Primary 2 Overlay支持快速显示、画面拉伸Linux i915 驱动对 KMS Plane 支持完善CRTC 原理CRTC 显示控制器的 “时序大脑 合成总入口”它决定屏幕怎么显示、什么时候显示、以什么分辨率 / 刷新率显示。DRM 里的抽象struct drm_crtc { struct drm_device *dev; const struct drm_crtc_funcs *funcs; const struct drm_crtc_helper_funcs *helper_private; struct drm_display_mode mode; // 分辨率、刷新率、时序 bool active; // 是否使能 struct drm_plane *plane; // 绑定的图层主图层 ... };硬件对应RockchipVOP海思 / 高通DC / DISPIntel/AMDPipe / CRTC全称CRT Controller阴极射线管控制器历史名字保留至今CRTC 核心三大功能生成显示时序最核心生成像素时钟 Pixel Clock生成行同步 HSYNC、场同步 VSYNC决定分辨率w/h刷新率60Hz/30Hz时序参数htotal/hsync/hback、vtotal/vsync/vback没有 CRTC屏幕根本不亮。驱动 Plane 图层读取像素数据CRTC 会按行扫描每读出一个像素 → 发给硬件合成按刷新率循环每秒 60 次全屏扫描扫描地址 Plane 绑定的 FB 地址CRTC 是所有 Plane 的 “读取时钟源”。控制图层合成与输出内部流程Plane0 ──┐ Plane1 ──┼──► 硬件合成器Blender──► CRTC 输出 Plane2 ──┘决定 Z-order决定 alpha 混合最终送给 Encoder → 屏幕CRTC 工作完整流程设置模式mode set计算 PLL 时钟配置时序使能 CRTCactive1启动时序发生器开始扫描读取 Plane 绑定的 FB按行读取显存合成 → 输出图像每次场同步发出 VBLANK 中断CRTC 与 Plane / Encoder / Connector 关系Plane ───┐ ├─► CRTC ───► Encoder ───► Connector ───► 屏幕 Plane ───┘最关键三句话CRTC 控制时序Plane 提供图像。一个 CRTC 可以挂多个 Plane。一个 Plane 只能属于一个 CRTC。CRTC 时序计算原理CRTC 时序的本质是模拟电子束逐行扫描屏幕的节奏LCD/LED 屏完全沿用 CRT 时代的逻辑所有参数最终都要换算成「像素时钟周期」驱动里通过配置硬件 PLL / 分频器实现。核心扫屏逻辑屏幕显示一帧画面的完整扫描过程┌─────────────────────────────────────────────────┐ │ 帧周期Frame Period 1/刷新率如 1/60≈16.67ms │ ├─────────────────────────────────────────────────┤ │ 行周期Line Period 帧周期 / 总行数VTotal │ ├─────────────────────────────────────────────────┤ │ 每行扫描 │ │ 1. 有效显示区HActive显示像素如 3840 │ │ 2. 行消隐区HBlank电子束回扫无显示 │ │ ├─ 行后沿HBackPorch稳定期 │ │ ├─ 行同步HSync同步脉冲屏幕识别行起始 │ │ └─ 行前沿HFrontPorch准备期 │ ├─────────────────────────────────────────────────┤ │ 全场扫描 │ │ 1. 有效显示区VActive显示行如 2160 │ │ 2. 场消隐区VBlank电子束回扫无显示 │ │ ├─ 场后沿VBackPorch稳定期 │ │ ├─ 场同步VSync同步脉冲屏幕识别帧起始 │ │ └─ 场前沿VFrontPorch准备期 │ └─────────────────────────────────────────────────┘有效区真正显示画面的区域分辨率 HActive × VActive消隐区屏幕不显示但 CRTC 仍在输出时钟用于电子束回扫 / 屏幕同步同步脉冲HSync/VSync屏幕的 “同步信号”告诉屏幕「新行 / 新帧开始了」。核心计算公式所有时序参数最终要换算成「像素数」或「行数」核心公式只有 3 个1像素时钟Pixel ClockPixel Clock (MHz) (HActive HBackPorch HSync HFrontPorch) × (VActive VBackPorch VSync VFrontPorch) × 刷新率 (Hz) / 10^6简化版Pixel Clock HTotal × VTotal × 刷新率 / 10^6HTotal 行总像素数VTotal 帧总行数2行周期 帧周期行周期 (μs) HTotal / Pixel Clock (MHz) 帧周期 (ms) VTotal × 行周期 (μs) / 1000 1 / 刷新率 (Hz)3消隐区占比驱动调优关键HBlank HTotal - HActive 行消隐像素数 VBlank VTotal - VActive 场消隐行数消隐区太小 → 屏幕闪屏 / 不同步消隐区太大 → 带宽浪费尤其 4K 场景。实战计算4K60Hz 示例以标准 4K60Hz3840×2160为例EDID 标准参数参数值说明HActive3840水平有效像素HBackPorch288行后沿HSync32行同步脉冲HFrontPorch128行前沿HTotal4400384028832128VActive2160垂直有效行VBackPorch33场后沿VSync8场同步脉冲VFrontPorch1场前沿VTotal220221603381刷新率60Hz帧率计算 Pixel ClockPixel Clock 4400 × 2202 × 60 / 10^6 ≈ 587.064 MHz和 HDMI 2.0 标准的 594 MHz 接近不同厂商会微调消隐区VBLANK 中断机制解决画面撕裂的核心VBLANK Vertical Blank即「场消隐期」—— 这是 CRTC 扫描完一帧、准备扫描下一帧的 “空窗期”VBLANK 中断就是在这个阶段触发的硬件中断。为什么需要 VBLANK 中断避免画面撕裂如果在 CRTC 扫描过程中更新 FB/Plane屏幕会同时显示新旧两帧 → 撕裂同步刷新在 VBLANK 期间更新画面CRTC 下一帧扫描时直接读取新数据 → 无撕裂帧率控制通过 VBLANK 中断计数精准控制帧率如 60Hz 对应每 16.67ms 一次中断。VBLANK 中断的触发时机帧周期 ┌─────────────────────────────────────────┐ │ 有效显示区VActive扫描画面 │ │ 无中断 │ ├─────────────────────────────────────────┤ │ 场消隐区VBlank │ │ ├─ VBackPorch稳定期 │ │ ├─ VSync同步脉冲 → 触发 VBLANK 中断 │ │ └─ VFrontPorch准备期 │ └─────────────────────────────────────────┘硬件触发时机CRTC 进入 VSync 阶段时自动触发 VBLANK 中断中断持续时间整个 VBlank 阶段4K60Hz 约 16.67ms × (2202-2160)/2202 ≈ 0.32ms。中断触发与处理VBLANK 中断必须和 CRTC 绑定每个 CRTC 有独立的 VBLANK 中断关闭中断要及时不用时关闭drm_crtc_vblank_off避免无用中断占用 CPU原子 KMS 依赖 VBLANK原子提交时DRM_MODE_ATOMIC_VBLANK_SYNC标志会强制等待 VBLANK 再生效低时延场景可关闭同步通过DRM_MODE_ATOMIC_NON_BLOCKING跳过 VBLANK 同步但会有撕裂。原子 KMS 核心机制原子 KMS 是现代 KMS 的核心其核心思想是所有显示状态变更以 “属性集合” 的形式一次性提交要么全部生效要么全部失败彻底解决传统 API 的 “中间状态” 问题。1. 核心概念属性Property每个 KMS 对象的可配置参数如 CRTC 的active、mode_idConnector 的crtc_id原子请求Atomic Request包含多个对象的属性变更集合提交标志DRM_MODE_ATOMIC_ALLOW_MODESET允许修改显示模式、DRM_MODE_ATOMIC_NON_BLOCKING非阻塞提交[8]。2. 原子提交流程用户态 → 内核态验证阶段核心为drm_atomic_helper_check驱动可重写该回调实现硬件特定校验如分辨率是否支持、Plane 缩放能力提交阶段通过vblank同步垂直同步保证画面无撕裂驱动回调atomic_commit完成寄存器配置。关键工作流程以 4K 显示为例结合嵌入式场景如运动相机完整流程如下1. 硬件初始化驱动 probeDRM 设备注册drm_dev_init()drm_dev_register()对象创建分配 CRTC、Plane、Encoder、Connector初始化其属性内存管理初始化 GEM/TTM支持 DMA-BUF 跨进程共享回调注册绑定atomic_check、atomic_commit等驱动回调。2. 显示模式探测用户态枚举 ConnectordrmModeGetConnectors()读取 EDIDdrmModeGetConnectorProperty()获取EDIDblob解析支持的 4K 模式如 3840×216060Hz创建模式 blobdrmModeCreatePropertyBlob()将显示模式存入内核。3. 帧缓冲区创建用户态分配 GEM 内存drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, ...)映射内存mmap()获取用户态指针写入 4K 像素数据创建 FramebufferdrmModeAddFB2()关联 GEM 句柄与像素格式。4. 原子提交启动显示分配请求drmModeAtomicAlloc()添加属性CRTCactive1、mode_id模式 blob IDPlanefb_id帧缓冲区 ID、crtc_idCRTC ID、源 / 目标矩形Connectorcrtc_idCRTC ID提交drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_ALLOW_MODESET, NULL)内核完成验证与硬件配置屏幕显示 4K 画面。5. 画面更新无闪烁创建新 Framebuffer或更新现有 GEM 内存原子提交仅修改 Plane 的fb_id无需重新设置模式内核在vblank时切换扫描缓冲区实现无缝更新。与 DRM 其他子系统的关联GEM/TTM内存管理核心Framebuffer 依赖 GEM 对象管理显存物理内存 / VRAM支持 CPU/GPU 一致性与 DMA-BUF 共享DRM Render负责 3D 渲染命令提交与 KMS 协同实现 “渲染 → 合成 → 显示” 全链路dma-buf跨进程 / 跨驱动内存共享标准支持视频解码如 V4L2与 KMS 合成的零拷贝VRM/DC特定硬件如 AMD的显示控制器抽象底层对接 KMS 对象模型。性能优化关键点嵌入式 / 低时延场景硬件合成利用多 Plane 实现视频 / UI 分层合成避免 CPU 软件合成Damage Tracking仅更新画面变化区域如drmModeAtomicAddProperty(req, plane_id, damage, ...)减少带宽占用vblank 同步避免画面撕裂低时延场景可使用DRM_MODE_ATOMIC_NON_BLOCKING并手动同步内存优化使用dumb buffer或prime buffer结合CMA连续内存分配提升嵌入式场景性能原子提交批量将多个属性变更合并为一次提交减少内核态 / 用户态切换。总结DRM KMS 以标准化对象模型抽象显示硬件通过原子提交保证状态一致性构建了从显存到屏幕的高效显示流水线。对于内核开发者核心是理解Plane/CRTC/Connector的拓扑关系实现正确的atomic_check/atomic_commit回调对于应用开发者关键是使用原子 API 完成模式设置与画面更新结合 GEM/dma-buf 实现内存高效管理。