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

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

DRM是目前Linux的主流图形显示框架，相比于传统FB架构，DRM允许多个程序同时使用视频硬件资源，管理多个程序的资源请求、访问，综上所述DRM更能适应日益更新的显示硬件，DRM优势主要体现：

DRM检测到的每个GPU都作为DRM设备，并为之创建一个设备文件/dev/dri/cardX与之连接，从整体架构上来看主要分为3个主要部分：

对底层接口进行封装，向上层提供通用的API接口，主要是对各种IOCTL接口进行封装，便于重用与代码共享。

正常工作时，需要设置显卡或者图形适配器的模式，主要体现在以下两个方面：

更新画面：显示buffer的切换，多图层的合成方式控制，以及每个图层的显示位置。

设置显示参数：包括分辨率、刷新率、电源状态（休眠唤醒）等。

提供内存管理方法，主要负责显示buffer的分配和释放。

图1.1 DRM图形显示框架总览

 资料直通车：Linux内核源码技术学习路线+视频教程内核源码

学习直通车：Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈

本章节介绍DRM框架中的一些重点模块的功能与在显示链路中的作用，下图为APP调用DRM到屏幕显示的流程框图。

图1.2 DRM图形显示框架框图

下表对DRM中KMS和GEM两个模型的不同组件进行概述性说明，辅以高通平台代码层级的对应关系说明，以加深架构与流程之间的对应联系。

DRM内部的Objects是组成DRM框架的核心，下图中蓝色部分为物理硬件的抽象，棕色部分则为软件的抽象，其中GEM结构体为：drm_gem_object，其余部分位于结构体drm_mode_object中.

PS：drm_panel不属于object范畴，只是为了降低LCD驱动与encoder驱动间的耦合，是一堆回调函数集合。

DRM的objects并不难理解，重要的是如何将实际的硬件与这些object进行关联，下面会以MIPI DSI接口为例进行介绍软件架构与DRM object的对应关系。

其中组件说明：

DRM代码非常庞大，显卡逻辑也非常复杂，在学习DRM架构时，需要通过实践对DRM的流程进行理解，以达到事半功倍的效果。

下面会以模式设置案例，对DRM架构的流程进行解析。modeset主要流程如下：

图3.1 DRM Modeset流程总览

DRM框架成功加载后，会创建一个设备文件/dev/dri/card0，上层用户应用可以通过该文件节点，获取显卡的各种操作。

打开DRM设备文件后，通过以下函数获取显卡的资源句柄，进而进行显卡资源的操作。

获取了drmModeRes后，获取它的连接对象。

创建FrameBuffer后，然后映射一片内存，对这块内存进行像素数据填充。

FB创建成功并进行清0操作，可以在里面填充任何数据，然后设置CRTC后，FB的内容就可以显示在屏幕。

CRTC模式设置函数：drmModeSetCrtc()，参数为：fd、crtc句柄、FB句柄、X\Y坐标等。

显示完成后，GUI会一直运行，一般不必实施资源清理工作。

本文介绍了DRM架构的发展历史、驱动框架以及简单示例，旨在帮助读者了解DRM架构的形成、功能流程实现，DRM代码庞大且复杂，想要深入理解它的内涵，最好的办法就是根据实际需求来进行代码流程梳理，后续章节也会对该部分进行展开讲解。

此外，DRM架构符合功能日益强大的现代显示设备，但仍有很多老的设备以及软件需要FB支持，在目前DRM框架中，会存在模拟FB设备的代码，参见drivers/gpu/drm/xxx/drv.c文件，会在设备目录下出现：/dev/fb0 。