传统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 。