参考：RK3399 探索之旅 / Display 子系统 / 基础概念

参考：DRM架构介绍（一）

前言: Linux 的两种显示方案

包括：

• FBDEV: Framebuffer Device

• DRM/KMS: Direct Rendering Manager / Kernel Mode Setting

它们有什么区别？

FBDEV：

• 传统的显示框架;
• 简单，但是只能提供最基础的显示功能;
• 无法满足当前上层应用和底层硬件的显示需求;

DRM/KMS：

• 目前主流的显示方案;
• 为了适应当前日益更新的显示硬件;
• 软件上能支持更多高级的控制和特性;

 DRM 是 Linux 目前主流的图形显示框架，相比 FrameBuffer 架构，DRM 更能适应当前日益更新的显示硬件。比如 FB 原生不支持多层合成，不支持 VSYNC，不支持 DMA-BUF，不支持异步更新，不支持 fence 机制等等，而这些功能 DRM 原生都支持。同时 DRM 可以统一管理 GPU 和 Display 驱动，使得软件架构更为统一，方便管理和维护。

 DRM 全称是 Direct Rendering Manager，进行显示输出管理、buffer 分配、帧缓冲。对应 userspace 库 为 libdrm,，libdrm 库提供了一系列友好的控制封装，使用户可以方便的进行显示的控制和 buffer 申请。DRM 的设备节点为 “/dev/dri/cardX”， X 为 0-15 的数值，默认使用的是/dev/dri/card0

从驱动的视角看：

传统linux显示设备驱动开发时，通常使用FB驱动架构，随着显卡性能升级：显示覆盖（菜单层级）、GPU加速、硬件光标，传统FB架构无法很好支持，此外，对于多应用的访问冲突也无法很好控制。在这样的背景下，DRM应用而生。

DRM是linux内核中负责与显卡交互的管理架构，用户空间很方便的利用DRM提供的API，实现3D渲染、视频解码和GPU计算等工作。

FrameBuffer

DRM

 目前大多数厂商已经抛弃fb框架，使用drm驱动来管理显示。其中的优点是芯片厂商不必重复造轮子，只需将自己显示处理器的配置流程实现为函数，由drm驱动调用即可。同时drm也为用户提供同一接口，方便使用。

DRM驱动模块

了解过drm的可能都看过下面这张图

DRM subsystem图：

虽然经常用 DRM/KMS 来指代整个 DRM subsystem，但是 KMS 和 DRM driver 只是 整个 DRM subsystem 的其中 2 个部分。

KMS (Kernel Mode Setting) 是内核提供给应用层的 DRM API 的其中一部分，应用层一般通过 libdrm 来访问这些 API。

对于驱动工程师而言，重点关注 DRM driver，这里负责使能 Display engine，可以理解为加强版的 FBDEV。

Linux内核DRM框架包括：GEM和KMS。展示DRM大体框架：

1、GEM

GEM（Graphic Execution Manager）:图形执行管理器，主要是对 FrameBuffer 的管理，如内存的申请、释放、共享和同步(GPU和CPU之间内存)机制等。

GEM常用的Buffer包括：

1）Dumb Buffer：基于cma api实现，只支持连续物理内存，用于小分辨率简单场景。

2）Prime Buffer：基于dma-buf实现的buffer共享机制，支持连续、非连续物理内存，用于大内存复杂场景。

2、KMS

KMS（Kernel Mode Setting）:内核显示模式设置，主要元素：Framebuffer、Plane、CRTC、Encoder、Connector。见下图：

1）Framebuffer：单个图层的显示内容，应用层和内核都可访问。

2）Plane：硬件图层，可实现多层合成显示，连接FB和CRTC。包括：Primary、Overlay和Cursor，驱动中至少实现1个Plane。

3）CRTC：对内存Buffer进行扫描，并转换成LCDC Timing信号。

4）Encoder：将CRTC输出的LCDC Timing时序转换成显示屏所需要的接口时序。

5）Connector：对应显示屏接口（HDMI、MIPI DSI、LVDS等）驱动和输出设备的相关状态信息（EDID、热插拔等）。