1. 课程导入
在 Linux 桌面世界里，图形显示并不是“一个程序把像素画到屏幕上”这么简单。从应用程序调用绘图接口，到最终显示器亮起像素，中间要经过窗口系统、合成器、显示服务器、图形驱动、内核 DRM/KMS 等多个层次。过去三十多年，这套体系的核心一直是 X11（X Window System）；而近十年，Wayland 逐渐成为现代 Linux 图形栈的主流方向。理解这次迁移，不只是记住几个新名词，而是理解 Linux 图形栈为什么演进、演进后各组件如何重新分工，以及迁移过程中会遇到哪些真实问题。
一、Linux 图形栈的演进背景
X11 诞生于 1984 年，设计目标是“网络透明”：客户端可以在远程机器上运行，通过 X 协议把绘图命令发送给本地 X Server。这个设计在 workstation 时代非常先进，但也带来了历史包袱。X11 的核心模型是：X Server 负责管理输入设备、窗口、光标和基本绘图，客户端通过 Xlib 或 XCB 与 Server 通信。窗口管理器（如 Mutter、KWin、Openbox）只是运行在 X Server 之上的一个特殊客户端，负责窗口边框、移动、缩放等策略。
随着桌面体验要求提高，合成器（Compositor）出现了。它把各个窗口的像素先渲染到离屏缓冲区，再做阴影、透明、动画、缩放等合成操作，最后输出到屏幕。问题在于：在 X11 架构下，合成器仍然要依赖 X Server 的窗口和输入模型，窗口内容、输入事件、渲染同步之间容易出现撕裂、延迟和权限边界模糊。于是 Wayland 被提出：它不再把“显示服务器”作为中心，而是让合成器直接承担显示服务器职责，客户端通过 Wayland 协议与合成器通信，合成器再通过 EGL/DRM/KMS 把最终画面送到显示设备。
二、X11 与 Wayland 的核心差异
从上面的结构对比可以看出，X11 与 Wayland 最大的区别在于“谁负责显示”和“谁负责合成”。X11 中，X Server 是中心，合成器只是客户端；Wayland 中，合成器本身就是显示服务器，客户端把缓冲区交给合成器，合成器决定如何显示。这个变化带来几个关键差异：
- 输入处理：X11 中，输入事件先到 X Server，再分发给客户端，合成器可能还要做一层转发；Wayland 中，合成器直接接收 libinput 事件，再按协议发送给焦点窗口，路径更短。
- 渲染同步：X11 的窗口内容与合成器之间缺少严格的帧同步，容易撕裂；Wayland 使用 buffer 提交、frame callback、explicit sync 等机制，让客户端和合成器按帧协作。
- 安全边界：X11 客户端可以监听全局输入、截屏、注入事件，权限边界模糊；Wayland 默认隔离客户端，截屏、录屏、全局快捷键需要经过 portal 授权。
- 网络透明：X11 天然支持远程显示；Wayland 协议本身面向本地，远程桌面通常需要 RDP、VNC 或 waypipe 等额外方案。
- 多 GPU / 多屏：X11 由 X Server 统一管理；Wayland 由合成器管理，不同合成器实现差异较大。
三、迁移的必要性与挑战
迁移到 Wayland 并不是“追新”，而是为了解决 X11 架构下越来越难处理的问题。现代桌面需要高 DPI、多屏不同刷新率、HDR、可变刷新率、触摸板手势、屏幕共享、沙箱应用、混合 GPU 等能力，这些在 X11 中往往需要大量扩展和补丁，而在 Wayland 中更容易从协议层统一。与此同时，X11 的输入延迟、撕裂、权限模型等问题，也促使发行版和桌面环境逐步把 Wayland 作为默认会话。
但迁移的挑战同样真实。首先是兼容性：大量老应用只支持 X11，需要 XWayland 作为兼容层；其次是工具链：xrandr、xinput、xdotool 等命令在 Wayland 下不再适用，需要替换为 wlr-randr、libinput、ydotool 或桌面环境自带工具；再次是桌面环境差异：GNOME、KDE Plasma、Sway、Hyprland 对协议支持程度不同，配置方式也各不相同；最后是排障方式变化：X11 下看 /var/log/Xorg.0.log，Wayland 下更多要看合成器日志、journalctl、WAYLAND_DEBUG 和 DRM 调试信息。
核心判断：迁移不是简单地把 X Server 换成 Wayland 合成器，而是把“显示服务器 + 窗口管理器 + 合成器”的职责重新组合。应用、工具链、桌面环境、远程方案、输入法、截屏录屏都要跟着调整。
四、典型场景与迁移检查清单
假设你有一台运行 Ubuntu 或 Fedora 的笔记本，当前使用 X11 会话，想切换到 Wayland。可以先做一次“迁移体检”：确认桌面环境是否支持 Wayland 会话，检查显卡驱动是否满足要求，列出依赖 X11 的工具和应用，再决定是整体切换还是先并行使用。
# 查看当前会话类型
echo $XDG_SESSION_TYPE
# 查看登录会话列表（GDM）
ls /usr/share/wayland-sessions/
# 检查 XWayland 是否可用
which Xwayland
# 查看合成器日志（以 GNOME 为例）
journalctl --user -u gnome-shell -b
# 查看 DRM 设备与驱动
ls /dev/dri/
cat /sys/class/drm/card0/device/uevent| 检查项 | X11 常见方式 | Wayland 对应方式 | 风险点 |
|---|---|---|---|
| 显示设置 | xrandr | 合成器设置 / wlr-randr | 多屏缩放、刷新率不一致 |
| 输入设备 | xinput | libinput / 桌面设置 | 触摸板手势、鼠标加速差异 |
| 截屏录屏 | import、scrot、ffmpeg x11grab | portal + PipeWire | 权限弹窗、应用未适配 |
| 远程桌面 | X11 forwarding、VNC | RDP、VNC、waypipe | 性能与剪贴板同步 |
| 自动化工具 | xdotool、wmctrl | ydotool、桌面专用接口 | 脚本需要重写 |
| 老应用 | 原生 X11 | XWayland 兼容 | 缩放模糊、输入法异常 |
五、常见误区与复盘思路
第一个误区是“Wayland 只是 X11 的替代品，换掉就行”。实际上，Wayland 是一组协议，具体行为由合成器决定，不同合成器之间差异很大。第二个误区是“XWayland 能解决所有兼容问题”。XWayland 让 X11 应用能运行，但它仍然是 X11 客户端，全局快捷键、截屏、拖放、剪贴板等能力可能受限。第三个误区是“迁移后性能一定更好”。性能取决于合成器、驱动、渲染路径和应用适配，某些场景下 X11 反而更稳定。
排障提醒：遇到 Wayland 问题时，先确认会话类型、合成器名称、显卡驱动和协议扩展，再判断是应用未适配、合成器未实现，还是权限 portal 未授权。不要直接套用 X11 时代的日志路径和命令。
六、课程学习目标与整体框架
本课程的目标是让你具备从 X11 迁移到 Wayland 的完整能力：理解图形栈分层与协议差异，掌握会话切换、应用适配、输入法、截屏录屏、远程桌面、多屏高 DPI、GPU 与驱动、排障与回退等关键环节。课程会沿着“背景与差异 → 环境准备 → 应用与工具链迁移 → 桌面环境实践 → 典型问题排障 → 生产落地”的路径展开，每一节都围绕真实命令、配置和判断依据，而不是停留在概念介绍。
学习完本课程后，你应该能够独立完成一次桌面环境的 Wayland 迁移评估，能够定位常见的黑屏、闪烁、输入法、截屏、远程桌面问题，并能够在必要时安全回退到 X11。接下来，我们会从图形栈的分层模型开始，逐步拆解每个组件的职责与迁移要点。