名词解释教学工作区 · 课程 0010 · 形态单概念 · 约 5 分钟 · 2026-10-01

Wayland:程序自己画,合成器拼一屏

你能做到:说清现代 Linux 桌面上「谁画、谁拼、谁上屏」这三步; 用 echo $XDG_SESSION_TYPE 认出当前是哪种会话; 遇到一个在新会话里不工作的截图、录屏或全局快捷键工具,知道它卡在哪一步、该走哪条申请通道。

1 | 定义

Wayland 是一套显示服务器协议(display server protocol): 规定客户端程序 client 怎么把自己画好的帧交给另一方, 那一方又怎么把输入事件发回给该收的程序。协议另一头真正干活的程序叫合成器 compositor(compositor),它同时兼任窗口管理器与显示服务器, 直接拿着显示与输入设备,把各客户端的缓冲区 buffer 拼成一屏推上屏幕。让只认上一代 X11(X.Org Server)的程序也能显示的兼容层,叫 XWayland。像把过去一间谁都能进的公共大画室,改成每人一间小画室:各画各的,画好整幅交给前台, 前台按位置拼成一整面墙挂出去;谁都没法顺手翻看别人桌上还没交的草稿。

2 | 它解决什么麻烦

上一代把所有人塞进同一个服务端,麻烦都出在这条谁都绕不过的必经之路上。

① 中间那一站谁也绕不过。客户端把渲染请求交给 X 服务端,由它驱动硬件、管前缓冲; 连合成器自己要把画面放上屏幕,也得再穿过它一次,每帧多几次来回。
② 合成器做过的变换,服务端不知道。窗口被缩放、旋转之后,「这次点击落在哪个窗口」就会算错。
③ 没有隔离。同一个服务端上的程序能看见别人的窗口内容、抓走整块键盘,也能把别的窗口挪走, 没有「只给我自己」这条界线。
④ 协议堆得太久。几十年的扩展都长在一个服务端里,新东西要一个个打补丁; 高分辨率屏幕的分数缩放、按窗口做帧同步这类需求,在旧结构里一直别扭。

3 | 它怎么解决

客户端程序自己渲染自己那份 -> 缓冲区 buffer 画好的一帧像素 -> Wayland 协议交帧与收输入都按它说话 -> 合成器 compositor 拼成一屏、管输入 -> DRM/KMS 内核里推帧上屏的接口 -> 屏幕

① 程序自己画。用 OpenGL、Vulkan 或软件渲染把这一帧画进自己的缓冲区,画完只报告「哪块更新了」; 合成器不代它画。
② 合成器直接接管设备。它经内核的 DRM/KMS 推帧、经 libinput 收输入,中间没有第二个服务端。
③ 交帧不搬像素。程序与合成器之间走一根 Unix 域套接字,递的只是「这块缓冲区好了」的通知; 显存里的像素不复制第二份,合成器拿到的是同一块对象。
④ 输入反过来算。合成器知道每块画面摆在哪儿、被缩放旋转过多少,能做逆变换, 把坐标还原成窗口内的位置再发回去。
⑤ 别人的画面拿不到。想要屏幕内容、想抢全局按键,得经 xdg-desktop-portal 这类门户 portal 申请。
⑥ 老程序由 XWayland 接住。XWayland 本身就是合成器的一个客户端,内部跑着一个 X 服务端; 老程序连它,它再把窗口交给合成器合成上屏。

4 | 用它的代价

① 合成器一崩,整场图形会话跟着崩。它是唯一管显示与输入的程序;它没了,所有客户端的连接一起断。上一代「窗口管理器崩了、程序还活着」那条退路,在这里没有了。
② 远程与串流没有上一代成熟。X11 协议天生网络透明,能把另一台机器上某个窗口显示到你屏幕上; 新协议明确不做这件事 —— 要远程只能整屏,由各合成器自己实现 RDP 或 VNC,单窗口转发没有通用方案。
③ 老程序与录制工具常常得绕路。XWayland 里的程序拿不到新能力;截图、录屏、全局快捷键都要门户支持, 没人实现就只能不用。
④ 驱动侧历史包袱重。NVIDIA 专有驱动对 Wayland 的支持长期落后,显式同步这类机制近两年才补齐; 老显卡、老驱动上容易出现撕裂、掉帧、多显示器异常。
⑤ 无障碍与自动化工具要重写。靠抓全局输入工作的老工具在新会话里失效, 替代品与各合成器自己的接口还在补齐。

5 | 真实使用场景

场景一:认出自己现在跑在哪种会话里。

echo $XDG_SESSION_TYPE          # 输出 wayland 或 x11
ls /usr/share/wayland-sessions  # 登录界面里能选到的 Wayland 会话

登录界面(GDM、SDDM)的会话菜单里,名字带 Wayland 的那几项就是走新协议; 登录进去之后再跑上面那条命令,能确认会话实际是哪一种 —— 这两条都在命令行界面(CLI)里敲,图形会话里开一个终端就能用。

场景二:把某个程序推上 Wayland 后端。

MOZ_ENABLE_WAYLAND=1 firefox                        # Firefox
chromium --ozone-platform=wayland                   # Chromium 系 / Electron
SDL_VIDEODRIVER=wayland ./game                      # SDL 游戏
steam -wayland                                      # Steam 客户端
flatpak override --socket=wayland org.example.App   # 让沙箱里的程序能用 Wayland

这些开关不一定都要写:新版程序与桌面环境常会自动挑。但程序在新会话里画面异常、输入迟钝时, 先确认它是不是还落在兼容层里。

场景三:发行版的默认值已经翻过去了。

GNOME 与 KDE Plasma 6 在新装的系统上默认起 Wayland 会话,Fedora、Ubuntu、Arch 装上就是; 老程序由 XWayland 兜住,所以多数人换了会话也感觉不到。

6 | 和相近的东西怎么分

先问一句:这句话说的是协议、是干活的程序,还是接老程序的桥?

名称	它是什么	和 Wayland 什么关系
X11(X.Org Server)	上一代的显示服务器协议与它最主流的实现:客户端把渲染请求交给它,由它代画、管前缓冲、管输入	被取代的那一代;两者分工正好相反 —— 旧的是服务端代画,新的是程序自己画
合成器(compositor)	同时兼任窗口管理器与显示服务器的常驻程序,合成各客户端的缓冲区、管显示与输入	协议另一头真正干活的角色;Wayland 只规定怎么说话,能力由它决定
GNOME Shell(Mutter)	GNOME 桌面的合成器,窗口管理、面板与合成在同一个进程里	合成器的一个具体实现;登录界面里选的那个会话,选的就是它
KWin	KDE Plasma 的合成器,同一份代码既能做 X11 会话也能做 Wayland 会话	另一个具体实现;开不开某项能力由它自己决定
Sway	面向键盘操作的平铺式合成器,只做 Wayland,配置沿用 i3 的写法	第三个实现;证明这套协议不绑定某个桌面环境
XWayland	以 Wayland 客户端身份运行的一个 X 服务端,专门接住只认 X11 的程序	兼容层;它显示出来的窗口照样由合成器合成,拿不到新能力
门户(xdg-desktop-portal)	沙箱程序申请屏幕内容、全局快捷键这类权限的统一接口	补上「读不到别人画面」之后的申请通道
DRM/KMS	内核里管显示控制器与页翻转的那层接口	合成器把拼好的一帧真正推上屏幕,靠的就是它

一句话分工:协议管「怎么说」,合成器管「拼一屏」,XWayland 管「接老程序」,门户管「要权限」。

7 | 常见误解

① 「Wayland 是一个桌面环境。」错在把协议当成产品:它只是一份协议加参考实现; 桌面环境提供的是实现它的合成器。所以没有「装一个 Wayland」这回事,能装的是合成器。
② 「换了 Wayland 就跑不了 X11 程序。」错在把兼容当例外:多数合成器自带 XWayland, 老程序照常打开;只是它拿不到截图、全局快捷键这类新能力。
③ 「Wayland 一定比 X11 快。」错在把「少几次搬运」当成「帧率更高」:省掉的是服务端那一站与一次复制, 实际快慢还看驱动、合成器与具体程序;有些路径(如某些远程与录制方案)反而更绕。
④ 「截图、录屏在新架构下就用不了。」错在把权限当缺失:能力还在,只是换了通道, 要经合成器或门户申请;工具没适配才不能用。

8 | 练习

三题自测,每题只有一个正确选项;选完立刻看到解释。

1. Wayland 本身到底是什么?

对。它是一套协议加一份参考实现;你机器上跑着的那个是合成器,拼屏与管输入都是它的事。

2. 一个只认 X11 的老程序,在新会话里靠谁显示出来?

对。XWayland 自己就是合成器的一个客户端,里面跑着一个 X 服务端;老程序连的是它, 它再把窗口交给合成器合成。

3. 客户端自己渲染完,交给合成器的是哪一样?

对。客户端在自己的缓冲区里画完,只把「哪块更新了」和缓冲区交给合成器;合成器不代画, 只做合成与上屏。服务端是上一代才有的角色。