[TOC]
Qcom DRM显示驱动架构
DRM原为Linux下的图形渲染架构(Direct Rendering Manager), 是device-independent内核级别驱动，内核提供直接访问硬件的权限， 原本是设计提供给PC使用来支持复杂的图形设备，后来也用于嵌入式系统上。而我们所属的的DRM，还包括KMS。
DRM/KMS概述
- 引入直接渲染管理器 (DRM) 来处理嵌入 GPU 的显卡
- 内核模式设置 (KMS) 是 DRM API 的一部分,可在给定的显示上设置模式
- 渲染和模式设置分为两个不同的 API,可以通过 /dev/dri/renderX 和 /dev/dri/controlDX 访问
- KMS 提供了一种配置显卡(或嵌入式系统)的显示管道的方法
- KMS 可替代帧缓冲区 dev (FBDEV)
| 功能 | FBDev | DRM/KMS |
|---|---|---|
| 上游 | 减少主动维护 不会提供所有功能(如叠加、游标) 现在鼓励开发人员迁移到 DRM/KMS |
通过开放源代码进行主动维护 更好地控制显示管道 图形 – 显示协议采用应用广泛的标准化架构 全套高级功能 |
| 用户/内核 API | 自定义叠加/原子提交 API | 标准(内核上游)API |
| 源管道管理 | 通过枚举索引和原子提交 IOCTL 进行管理 通过 DPU 驱动程序功能公开的功能 |
通过属性和原子模式设置提交管理的平面对象 通过平面属性公开的功能 |
| 层混合器管理 | 在驱动程序中处理,用户模式下难以了解当前动态 | 驱动程序中的默认分配。用户模式可以查询和覆盖,虚拟化在 CRTC 中得到处理 |
| 面板管理 | 通过多个 sysfs 节点进行管理 | 通过连接器对象属性进行管理 |
DRM/KMS构成
先来看一个图：
帧缓冲区 (struct drm_framebuffer)
帧缓冲区是抽象的内存对象,可提供一个扫描输出到 CRTC 的像素源。实现取决于使用的内存管理器和 IOMMU 功能。平面 (struct drm_pane)
一个平面代表一个图像源,可以在扫描输出过程中与 CRTC 混合或叠加在 CRTC 之上。
平面与帧缓冲区相关联,以裁剪映像内存(源)的一部分,并选择将其缩放到目标尺寸。最终会与 CRTC 混合或叠加在 CRTC 之上。CRTC (struct drm_crtc)
CRT 控制器 (CRTC) 不只与 CRT 显示有关,它还能配置适当的显示设置:显示计时/分辨率,将帧缓冲内容扫描输出到一个或多个显示等等。编码器 (struct drm_encoder)
从 CRTC 获取像素数据并将其转换为适合任何已连接的连接器的格式。连接器 (struct drm_connector)
表示显示接口(HDMI、DisplayPort、DSI、VGA),将信号传输到显示,检测显示,曝光模式等。桥接器
与编码器相关联,参与模式设置,设备电源管理,连接检测等。
高通HAL层实现
HAL实现，采用了Device和Resource分离的方式，Resource采用了私有库封装，看不了代码。Device又采用了3层接口设计，第一层HWCDisplay和Session强相关，也就是和Android系统强相关，第二层DisplayInterface是HWC的逻辑层，第三层HWInterface是和底层的驱动实现相关。
目前高通，HWInterface分为两种实现，一种直接基于FB驱动实现，另外一种也是目前在用的，基于DRM驱动架构实现。
DRM抽象了DRMManager进行管理，抽象的DRMConnectorManager，DRMCrtcManager，DRMConnectorManager，DRMPlaneManager和前面所说的DRM/KMS的组成对应。
所以，对整个显示流程来说，数据流是这样的：
小结
这里只是概要性的讲了一下DRM显示。不破戒了，后续更新！
