Wayland文档翻译

# 第1章. 引言

## 目录

- 动机
- 合成管理器作为显示服务器

## 动机

大多数基于 Linux 和 Unix 的系统在构建位图图形界面的底层协议方面依赖于 X Window 系统（简称 X）。在这些系统上，X 栈已经扩展到涵盖一些功能，这些功能可能更适合位于客户端库、辅助库或主机操作系统内核中。像 PCI 资源管理、显示配置管理、直接渲染和内存管理等支持已经集成到了 X 栈中，导致了一些限制，比如对于独立应用的有限支持，在其他项目中的重复（例如 Linux fb 层或 DirectFB 项目），以及对于组合多个元素的系统而言复杂度很高（例如在 fb 驱动程序和 X 驱动程序之间进行 radeon 内存映射处理，或者 VT 切换）。

此外，X 已经发展到并纳入了现代功能，如离屏渲染和场景合成，但受限于 X 架构的限制。例如，X 的合成实现会增加额外的上下文切换，并使诸如输入重定向之类的事情变得复杂。

 

上图说明了X服务器和合成器在操作中的核心作用，以及将内容呈现在屏幕上所需的步骤。

随着时间的推移，X 开发人员逐渐认识到这种方法的缺点，并开始进行拆分。在过去的几年里，许多功能已经从X服务器中移出，转移到了客户端库或内核驱动程序中。最早移出的一个组件是字体渲染，freetype 和 fontconfig 提供了核心X字体的替代方案。在客户端库中作为图形驱动程序的直接渲染OpenGL经历了一些迭代，最终成为DRI2，它将大部分直接渲染缓冲管理从客户端代码中抽象出来。然后，cairo出现了，提供了一个独立于X的现代2D渲染库，而合成管理器接管了桌面渲染的控制，因为诸如GTK+和Qt这样的工具包不再使用X API进行渲染。最近，内存和显示管理已移至Linux内核，进一步减小了X及其驱动程序栈的范围。最终的结果是一个高度模块化的图形堆栈。
 

## 合成管理器作为显示服务器

Wayland 是一种全新的显示服务器和合成协议，而 Weston 则是这个协议的实现，构建在上述所有组件的基础之上。我们试图提炼出 X 服务器中仍然被现代 Linux 桌面使用的功能。结果证明这并不多。应用程序可以分配自己的离屏缓冲区，并直接渲染其窗口内容，使用像 libGL 这样的硬件加速库，或者高质量的软件实现，比如 Cairo 中的实现。最终，所需的是一种将生成的窗口表面呈现出来以供显示的方法，以及一种在多个客户端之间接收和仲裁输入的方法。这就是 Wayland 提供的功能，通过以稍微不同的方式将已经在生态系统中的组件拼凑在一起。

X 仍然会一直存在，就像 Fortran 编译器和 VRML 浏览器一样，但现在是时候考虑将其从关键路径中移出，并将其作为遗留应用程序的可选组件提供。

总体而言，Wayland 的理念是为客户端提供一种管理窗口及其内容显示的方式。渲染留给客户端，系统范围的内存管理接口用于在客户端和合成管理器之间传递缓冲区句柄。

上图说明了Wayland客户端如何与Wayland服务器交互。需要注意的是，窗口管理和合成完全由服务器处理，通过减少上下文切换在一定程度上提高了性能，同时显著降低了复杂性。由此产生的系统比类似的X系统更易于构建和扩展，因为通常只需要在一个地方进行更改。或者在协议扩展的情况下，只需要两个地方（而不是像在X系统中可能需要更新窗口管理和/或合成处理的3或4个地方）。