「Wayland」-

0

认识

官网：https://wayland.freedesktop.org/
文档：https://wayland.freedesktop.org/docs/html/
仓库：https://gitlab.freedesktop.org/wayland

Wayland is a replacement for the X11 window system protocol and architecture with the aim to be easier to develop, extend, and maintain. 简而言之，Wayland 是个现代、简洁、高效的显示服务器协议，旨在取代旧的 X11。它不仅仅是个软件，更是套规范，其定义客户端（应用程序）如何与显示服务器进行通信。

我们为什么需要 Wayland？是因为 X11 的问题，要理解 Wayland 的优势，首先要了解 X11 的历史包袱：

  • 架构过时：X11 诞生于 80 年代，当时网络透明性是主要目标（在一台机器上运行程序，在另一台机器上显示）。这意味着它的架构非常复杂，包含了大量在现代本地桌面环境中不再需要的代码路径和协议。
  • 职责混杂：X 服务器试图做太多事情：处理输入（键盘、鼠标）、渲染图形、管理窗口、网络通信等。这导致其代码庞大，难以维护和扩展。
  • 安全模型薄弱：在 X11 中，任何应用程序都可以监听其他程序的键盘输入、截取其他程序的屏幕内容。这在现代多任务操作系统中是一个严重的安全隐患。
  • 现代图形技术的“补丁”：为了支持 OpenGL、平滑动画、混合效果等现代图形技术，需要在 X11 之上叠加一堆扩展（如 GLX, DRI, Composite 等），这使得整个图形栈变得臃肿和低效。

组成

https://wayland.freedesktop.org/architecture.html

Wayland 架构的核心思想是：将合成器（Compositor）作为显示系统的核心。

Wayland 的设计哲学是 “简单和正确”，它从底层重新思考了在拥有现代内核和图形驱动的前提下，显示服务器应该如何工作。

Wayland is the language (protocol) that applications can use to talk to a display server in order to make themselves visible and get input from the user (a person).

客户端 | Wayland Client

  • 这就是我们的应用程序（例如 Firefox, LibreOffice）。
  • 它链接了 Wayland 客户端库（`libwayland-client`），用于与合成器通信。

合成器 | Wayland Compositor

A Wayland server is called a “Compositor”.

合成器是现代图形系统的“导演”和“引擎”。它不再像旧的 X Server 那样只是一个被动的消息中转站，而是一个主动的、集权的管理者，负责协调所有应用程序的视觉输出和用户输入，最终创造出我们看到的那个连贯、流畅、安全的桌面体验。Wayland 的成功，很大程度上就在于它确立了合成器在这一架构中的核心地位。

Compositor 是 Wayland 架构的核心和大脑。Compositor 集 3 种关键角色于一身，这与传统的 X11 架构有根本区别：

  1. 显示服务器：管理所有客户端连接的“主持人”。
    • 职责：管理所有应用程序（Wayland 客户端）的连接，是客户端通信的唯一端点。
    • 具体工作：监听 Wayland 套接字，接受客户端的连接，处理客户端根据 Wayland 协议发送的请求（如创建表面、注册输入设备等）。

  1. 窗口管理器：负责窗口的布局、装饰、切换等。
    • 职责：决定应用程序窗口在屏幕上的布局、外观和行为。
    • 具体工作：
      • 控制窗口的位置、大小、堆叠顺序（哪个窗口在上，哪个在下）。
      • 绘制或管理窗口装饰（标题栏、边框）。
      • 处理用户发起的窗口操作，如最大化、最小化、平铺、拖拽移动等。

  1. 合成管理器：将各个客户端提供的缓冲区合成为最终的屏幕图像。
    • 职责：这是合成器最核心、最技术性的角色——将多个独立的图像源合成为一幅最终的画面。
    • 具体工作：
      • 从各个客户端接收它们已经绘制好的缓冲区。
      • 应用所需的视觉效果，如窗口阴影、半透明、动画（最小化、缩放）。
      • 根据窗口的堆叠顺序，将所有缓冲区和效果混合在一起。
      • 将最终生成的图像直接提交给内核的显示驱动（如 Linux 的 `DRM/KMS` 子系统），呈现在屏幕上。

Compositor 的工作流程详解

  1. 启动
    • 合成器启动，初始化图形硬件（通过 DRM/KMS），获取显示器的独占控制权。
    • 它开始监听 Wayland 套接字，等待客户端连接。

  1. 客户端连接与窗口创建
    • 我们打开了 Firefox。Firefox（Wayland 客户端）连接到合成器。
    • Firefox 请求创建一个 `wl_surface`（表面），这是 Wayland 中最基本的绘图单元。

  1. 渲染阶段
    • Firefox 使用 OpenGL 或 Vulkan 等图形 API，在自己的内存中（后台缓冲区）绘制好网页界面。
    • 绘制完成后，Firefox 通知合成器：“我的表面内容已经更新，准备好了。” 它将其缓冲区句柄传递给合成器。注意：Firefox 不直接接触屏幕帧缓冲区。

  1. 合成阶段
    • 合成器接收到通知。它知道 Firefox 窗口的位置、大小和堆叠顺序（比如它在终端窗口之上，但在文件管理器之下）。
    • 在下一个垂直同步 信号到来时（为了避免屏幕撕裂），合成器开始工作：
      1. 它从 Firefox 获取已准备好的缓冲区。
      2. 它也从其他可见的窗口（终端、文件管理器）获取它们的缓冲区。
      3. 它可能为每个窗口加上阴影、进行缩放或应用半透明效果。
      4. 它使用 GPU 将所有这些图像层按照正确的顺序混合，生成最终的一帧图像。
      5. 它将这帧图像提交给内核，由内核通过显示控制器扫描输出到显示器。

  1. 输入处理阶段
    • 我们移动了鼠标。内核产生一个鼠标移动事件，直接发送给合成器。
    • 合成器根据鼠标光标的位置，判断它正位于 Firefox 的窗口之上。
    • 合成器将这个鼠标移动事件转发给 Firefox 客户端。
    • Firefox 接收到事件后，可能会做出反应（例如改变光标形状或高亮链接），并重新渲染其界面，然后回到第 3 步。

著名的 Wayland 合成器示例：

  • GNOME：使用 Mutter 作为其合成器。
  • KDE Plasma：使用 KWin 作为其合成器。
  • Sway：是个平铺式窗口管理器，是 i3wm 的 Wayland 替代品。
  • Weston：Wayland 项目的参考实现，用于演示和测试。

协议

  • Wayland 核心协议：定义了最基本的对象和请求，例如，如何建立连接、创建表面、处理输入、……
  • 扩展协议：由于 Wayland 核心协议非常精简，更多功能（例如，桌面 shell 集成、指针锁定、数据共享、……）通过扩展协议提供。这类似于 Web 浏览器支持的扩展 API。

其他组件

libwayland

A core part of Wayland architecture is libwayland: an inter-process communication library that translates a protocol definition in XML to a C language API. This library does not implement Wayland, it merely encodes and decodes Wayland messages. The actual implementations are in the various compositor and application toolkit projects.

性质

—— 根据其架构，Wayland 带来了诸多好处与功能。

提供简单地代码开发

协议本身非常精简，减少了代码复杂性和潜在的 Bug。

Wayland 的工作流程与核心理念，Wayland 的工作方式可以概括为：应用程序只负责绘制，合成器负责所有其他事情。

  • 统一且现代的图形栈：从应用到底层驱动，整个图形流程是为现代 GPU 和操作系统设计的，不再需要为旧协议打补丁。
  • 易于开发和维护：对于合成器开发者来说，代码库更清晰；对于应用开发者来说，图形 API 的使用更直接。

#### 1. 渲染流程：客户端负责渲染

  • 应用程序（客户端）直接与 GPU 对话（通常通过 EGL、OpenGL ES、Vulkan 等 API），在自己的缓冲区中绘制好界面内容。
  • 绘制完成后，客户端将这个缓冲区的句柄传递给 Wayland 合成器，并通知合成器：“我的这个表面（Surface）需要更新了。”
  • 合成器接收到通知后，会在合适的时机（例如下一个垂直同步信号）获取这个缓冲区，并将其与其他窗口、桌面背景等合成，最终输出到屏幕上。

关键点：客户端不直接向屏幕绘制像素。它只提供一个已经绘制好的图像块（缓冲区），由合成器统一安排和合成。这被称为“客户端渲染”。

简化与稳定

  • 将显示、窗口管理和合成功能整合到一个进程中，减少了组件间的通信开销和复杂性，整个图形栈更稳定。

灵活性

  • 合成器开发者可以自由实现各种视觉效果和窗口管理策略，而无需修改底层协议或破坏应用程序的兼容性。这就是为什么我们有 GNOME Shell、KDE Plasma 和 Sway 等体验迥异的桌面环境，它们都是不同的 Wayland 合成器。

✅️ 提供更好的性能与流畅性

应用程序直接渲染到它能控制的缓冲区，合成器直接使用这个缓冲区。消除了 X11 中不必要的内存拷贝和数据中转（例如，整个 X11 渲染管线）。

在 X11 中，其同样存在 Compositor 组件。但是，其仅是个建立在 X11 上的“补丁”。当进行渲染时：

1、应用程序渲染到自己的缓冲区。

2、应用程序通过 X11 协议，将这个缓冲区发送给 X Server。

3、X Server 接收并处理这个请求。

4、Compositor 再从 X Server 那里获取这个缓冲区的数据。

5、Compositor 进行合成，并将最终结果输出到屏幕。

步骤 2 和 3 是完全不必要的内存拷贝和上下文切换，增加了延迟和开销。

在 Wayland 中，Compositor 就是核心，没有任何中间层，自己就是显示服务器。它直接与内核的显示和输入设备（通过 DRM/KMS 和 libinput）通信，是系统中所有图形应用程序连接的唯一端点。

可以更好地与 GPU 调度和垂直同步配合，提供无撕裂、流畅的动画效果。整个流程更贴近现代 GPU 的工作方式，使得无撕裂（VSync）和流畅动画更容易实现。

✅️ 提供安全性保障

强隔离的架构防止了应用程序间的窥探和输入监听。

  • 合成器直接输入处理，输入事件由合成器统一派发，应用程序无法监听全局键盘或鼠标事件。
  • 应用程序无法截取其他应用程序的屏幕内容，除非通过明确的、用户授权的机制（例如，PipeWire Portal）。

  • 所有的输入事件（键盘、鼠标、触摸）首先由内核（通过 `libinput` 等）传递给 Wayland 合成器。
  • 合成器根据光标位置和窗口堆叠顺序，判断这个输入事件应该发送给哪个客户端。
  • 然后，合成器将输入事件直接转发给目标客户端。

关键点：输入路径是单向的。合成器是输入事件的唯一仲裁者，客户端无法窥探其他客户端的输入。这从根本上解决了 X11 的输入安全问题。

应用

目前，2025-11-21，几乎所有主要的 Linux 发行版（如 Fedora, Ubuntu, Arch Linux）在其默认的 GNOME 或 KDE Plasma 桌面环境中，都已将 Wayland 作为默认的显示服务器。它代表了 Linux 桌面图形未来的发展方向。

Q：判断当前为 X11 或 Wayland 环境？
A：echo $XDG_SESSION_TYPE
R：How to Check if You are Using Wayland or Xorg?

改进

NVIDIA 显卡支持：历史上，NVIDIA 对其专有驱动对 Wayland 的核心技术（GBM）支持不佳，带来了很多问题。不过，近年来情况已大幅改善，NVIDIA 正在积极跟进。

X11 应用的兼容性：大量旧有的 X11 应用程序无法直接在 Wayland 上运行。解决方案是使用 XWayland，这是一个在 Wayland 上运行的、精简的 X11 服务器。它像一个“翻译官”，将 X11 客户端的请求转换为 Wayland 协议。对用户来说，这个过程是无感的，大多数 X11 程序都能正常工作。

屏幕录制和远程桌面：由于安全模型限制，截屏和录屏在 Wayland 上不再像 X11 那样随意。需要通过专门的 Portal（如 PipeWire）向合成器请求权限。现在，主流工具（如 OBS, Discord）都已支持这种方式。

参考

DeepSeek / 介绍 wayland 架构
DeepSeek / 介绍 compositor 合成器的概念