3. Linux图形栈概览
在车载 HMI 工程中，应用层看到的“画面”只是最终结果，真正决定帧率、延迟、撕裂、内存占用和多屏一致性的，是 Linux 图形栈各层之间的协作方式。理解 DRM/KMS、GEM、Mesa、EGL、OpenGL ES、Vulkan 与 Wayland 的关系，是后续做合成器选型、性能调优和故障定位的基础。
一、核心原理：从应用到显示的纵向分层
Linux 图形栈可以按“应用接口层—图形 API 实现层—内核显示与内存层—硬件层”来理解。Wayland 是协议与合成器体系，负责窗口管理、输入分发和客户端缓冲区提交；EGL 是 OpenGL ES 与本地窗口系统之间的胶水层；OpenGL ES 和 Vulkan 是应用直接调用的渲染 API；Mesa 是这些 API 在 Linux 上的主要开源实现；GEM 负责图形缓冲区对象的内存管理；DRM/KMS 则是内核中直接管理显示控制器、CRTC、连接器和帧缓冲的子系统。
关键点在于：Wayland 不直接画图，它管理的是“谁把什么缓冲区在什么时候提交给合成器”。合成器通常通过 EGL 创建上下文，用 OpenGL ES 或 Vulkan 完成合成，再把最终缓冲区交给 DRM/KMS 扫描输出。GEM 则贯穿其中，保证缓冲区能在 GPU、合成器和显示控制器之间安全共享。
二、方法流程：一帧画面如何从应用走到屏幕
以 Wayland 客户端提交一帧为例，典型路径如下：
- 应用通过 EGL 创建上下文和窗口表面，调用 OpenGL ES 或 Vulkan 渲染到缓冲区。
- 渲染完成后，应用通过 Wayland 协议把缓冲区提交给合成器。
- 合成器用 EGL 导入该缓冲区，作为纹理参与合成，生成最终帧。
- 合成器通过 DRM/KMS 的原子提交或页面翻转，把最终帧交给显示控制器扫描输出。
- GEM 在整个过程中管理缓冲区的分配、共享和释放，避免不必要的拷贝。
一句话记忆：Wayland 管“提交与合成”，EGL 管“连接”，OpenGL ES/Vulkan 管“渲染”，Mesa 管“实现”，GEM 管“内存”，DRM/KMS 管“上屏”。
三、案例/场景：车载多屏 HMI 的典型链路
假设一辆车有仪表屏和中控屏，仪表用 Qt 渲染，中控用 Flutter 渲染，两者都跑在同一个 Wayland 合成器下。仪表要求低延迟、高刷新，中控允许稍高延迟。此时合成器需要为两个客户端分别管理缓冲区，并通过 DRM/KMS 的多个 CRTC 分别驱动两块屏幕。
# 查看 DRM 设备与连接器状态
ls /dev/dri/
modetest -M rockchip -c
# 查看 Wayland 合成器使用的后端
echo $WAYLAND_DISPLAY
weston --backend=drm-backend.so --tty=2
# 查看 EGL 与 OpenGL ES 信息
eglinfo -B
glxinfo | grep "OpenGL ES"如果仪表屏出现撕裂，优先检查合成器是否使用了页面翻转与同步机制；如果中控屏掉帧，优先检查 GEM 缓冲区是否频繁分配释放，以及 Mesa 驱动是否走了软件回退路径。
四、误区与复盘：常见理解偏差
| 常见误区 | 正确理解 |
|---|---|
| Wayland 就是显示驱动 | Wayland 是协议与合成器体系，真正上屏靠 DRM/KMS |
| EGL 只属于 OpenGL ES | EGL 也用于 Vulkan 与本地窗口系统集成，负责上下文和表面管理 |
| Mesa 只是 OpenGL 实现 | Mesa 同时覆盖 OpenGL ES、Vulkan、EGL 及多种驱动后端 |
| GEM 就是显存 | GEM 是缓冲区对象管理框架，具体内存类型由驱动和硬件决定 |
| DRM 只负责显示 | DRM 还包含渲染节点、内存管理和同步对象等能力 |
排障建议：先确认应用走的是硬件渲染还是软件回退，再确认合成器是否使用 DRM/KMS 原子提交，最后检查 GEM 缓冲区是否被频繁重建。这三步能覆盖大部分车载 HMI 图形性能问题。
注意：不同 SoC 厂商的 DRM 驱动、Mesa 版本和 EGL 实现差异较大，车载项目应尽早锁定 BSP 与图形栈版本，避免后期因驱动行为不一致导致合成器适配成本上升。
掌握这张纵向关系图后，后续无论是选择 Weston、KWin 还是自研合成器，都能清楚判断每一层该由谁负责、性能瓶颈可能出现在哪里，以及如何用工具验证每一段链路是否正常工作。