📚 课程目录第2章图形系统基础

2. 图形系统基础

在嵌入式与移动端做图形开发，绕不开三个基础问题：画面从应用到屏幕经过了哪些层？显示协议选 X11 还是 Wayland？渲染 API 为什么普遍是 OpenGL ES 而不是桌面 OpenGL？本节把这三件事串成一条主线，为后续 OpenGL ES 与 Wayland 的集成打底。

一、Linux 图形栈的分层结构

Linux 图形栈可以按“应用—渲染—合成—显示—硬件”五层理解。最上层是应用与工具包（Qt、GTK、Flutter、Chromium 等）；其下是渲染 API 层，包括 OpenGL ES、Vulkan、EGL；再往下是窗口系统与合成器，即 X11 或 Wayland 的 compositor；然后是内核侧的 DRM/KMS 与 GEM 显存管理；最底层是 GPU、显示控制器和屏幕。

关键接口是 EGL：它负责把渲染 API 与本地窗口系统连接起来，管理 surface、context 和 buffer 交换。应用通常不直接调用 DRM，而是通过 EGL 或合成器提供的协议完成上屏。理解这条链路，才能定位“黑屏、撕裂、掉帧”发生在哪一层。

二、X11 与 Wayland 的对比

X11 诞生于 1984 年，采用“客户端—服务器”模型：应用是客户端，X Server 负责窗口管理、输入分发和绘制。它的优点是生态成熟、网络透明、远程显示方便；缺点是协议陈旧、合成路径长、安全模型弱（任意客户端可监听全局输入），在高帧率、低延迟场景下开销明显。

Wayland 把“显示服务器”和“合成器”合并，客户端直接渲染到自己的 buffer，再通过协议把 buffer 交给 compositor 合成上屏。它更简洁、延迟更低、天然支持每窗口独立渲染与安全隔离。代价是协议较新、部分旧应用需要 XWayland 兼容层，且 compositor 承担了更多职责。

对比维度	X11	Wayland
架构模型	客户端 / 独立 X Server	客户端 / 合成器一体
渲染路径	应用→X Server→合成器	应用→合成器→DRM
延迟与开销	较高，多一次拷贝	较低，buffer 直传
安全隔离	弱，全局输入可被监听	强，按 surface 授权
远程显示	原生支持	需额外方案（如 RDP、VNC）
嵌入式适配	较重，依赖多	轻量，适合定制 compositor

在嵌入式产品中，若追求低延迟、低内存和可裁剪，Wayland 通常是更优选择；若需兼容大量遗留 X11 应用，可保留 XWayland 过渡。

三、OpenGL ES 在嵌入式与移动端的定位

OpenGL ES 是 OpenGL 的嵌入式子集，去掉了大量冗余特性，保留核心的顶点/片元管线、纹理、FBO、着色器等能力。它在移动端和嵌入式 GPU 上拥有最广泛的驱动支持，是 Android、iOS、以及大量 Linux 嵌入式平台的默认图形 API。

与桌面 OpenGL 相比，OpenGL ES 更强调：

低功耗与低带宽：适合电池供电和内存受限设备。
固定管线裁剪：只保留可编程管线，减少驱动复杂度。
与 EGL 强绑定：通过 EGL 管理本地窗口与上下文。
版本演进清晰：ES 2.0 可编程管线、ES 3.x 增强特性、ES 3.2 接近现代能力。

在 Wayland 集成中，OpenGL ES 通常与 EGL 配合：应用创建 EGLSurface，渲染完成后通过 eglSwapBuffers 提交；compositor 再通过 Wayland 协议接收 buffer 并合成。若使用 DMA-BUF，还能实现零拷贝共享，进一步降低延迟。

// 典型 EGL + OpenGL ES 初始化片段（伪代码）
EGLDisplay dpy = eglGetDisplay(EGL_DEFAULT_DISPLAY);
eglInitialize(dpy, &major, &minor);

EGLConfig cfg;
EGLint cfgAttrs[] = {
    EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
    EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
    EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8,
    EGL_NONE
};
eglChooseConfig(dpy, cfgAttrs, &cfg, 1, &numConfigs);

EGLSurface surf = eglCreateWindowSurface(dpy, cfg, nativeWindow, NULL);
EGLContext ctx = eglCreateContext(dpy, cfg, EGL_NO_CONTEXT, ctxAttrs);
eglMakeCurrent(dpy, surf, surf, ctx);

// 渲染循环
while (running) {
    glClear(GL_COLOR_BUFFER_BIT);
    // ... 绘制 ...
    eglSwapBuffers(dpy, surf);
}

四、案例与常见误区

以一个嵌入式 HMI 项目为例：设备使用 Mali GPU，系统基于 Wayland compositor。应用层用 Qt Quick，底层走 OpenGL ES + EGL。若出现画面撕裂，常见原因是未开启垂直同步或 compositor 未正确使用 page flip；若出现黑屏，则优先检查 EGL 是否成功绑定到 Wayland 的 wl_surface，以及 DRM 权限是否被正确授予。

常见误区：把 X11 的“X Server 负责绘制”思维带到 Wayland。Wayland 下客户端自己渲染，compositor 只做合成与提交，因此应用必须自己管理 EGL 上下文和 buffer 生命周期。

复盘时建议按“应用→EGL→合成器→DRM→屏幕”的顺序逐层验证：先确认 EGL 初始化成功，再确认 buffer 能正常提交，最后确认 DRM 输出模式与刷新率匹配。这样能把问题快速收敛到具体层，而不是在整条链路上盲目猜测。