这个是Wayland官网文章的翻译。原文链接：https://wayland.freedesktop.org/faq.html

主页（已翻译）：https://bbs.deepin.org/post/256834

---

Wayland常见疑问

怎么又做了一个X服务器？

其实Wayland并不是一个X服务器，当然也不是X的分支。他只一个合成器和客户端通信的协议。合成器把输入事件传递给客户端，而客户端直接渲染内容，与显存中的缓冲区交互，然后把这些缓冲区的更新信息告知合成器。

采用什么许可证？

Wayland使用MIT Expat license（原文）授权。

这岂不是要把所有的工作再做一遍？

Wayland其实没有再做那么多工作。Wayland会在任何可能的地方尽量重复利用已有的驱动程序和基础设施。这个项目的一个可取之处是Wayland重复利用了DRI驱动、内核端的GEM调度器和KMS。Wayland不需要去与其他的项目争夺驱动程序开发者的特别关注，X.org、mesa和drm社区做的硬件支持和驱动开发工作会直接使Wayland受益。

用的什么绘图API?

你想用啥都可以！Wayland并不会代替客户端的渲染工作，而是让客户端自己去用他喜欢的方式，绘图到一个共享的缓冲区。他绘制结束后就通知Wayland服务器（合成器）内容的变更。目前的测试客户端通常使用Cairo软件渲染、Cairo的OpenGL渲染或者直接使用OpenGL硬件加速。另外，多媒体架构也可以直接把他们用的缓冲区共享到Wayland服务器。任何一个能渲染到共享缓冲区中的用户端绘图库都可以完成这个工作。

Wayland能替换掉X服务器吗?

几乎算是可以了。现在用户会话通过很多合成器都能在Wayland中运行：我们自己的Weston还有Enlightenment、GNOME Shell、KDE和很多其他的在开发中的合成器。几乎所有工具包都有Wayland端口，并且比如说GStreamer和SDL这类的架构也完全可以运行到一个纯原生的Wayland会话上，和你现在使用的桌面一样。

虽然说一些客户端必须依赖X11运行，并且以后也会一直如此。为了这种情况，XWayland能作为Wayland合成器的一个插件，来运行一个真正的X服务器。这样过时的客户端就能用一个真正的X11平台来支持他们运行，他们会和原生的Wayland客户端在你的Wayland会话中一同显示。

为什么不给X服务器增加功能呢？

因为我们终于有一次机会不做那种事了。其实我们可以把Wayland的缓冲区交换和更新模型通通合并进X，但是我们也有一个选择，让X从客户端和硬件之间数据交换的疯狂战线中退役，而让他仅作为一个用于兼容的可选项目。现在的情况和从前是不一样的，有很多基础设施已经从X服务器转移到了内核（内存管理、命令调度、KMS）及各种库（cario、pixman、freetype、fontconfig、pango等）中，中心的服务器进程只剩下了非常小的一部分。（译注：想表述的是，X服务器的很多功能已经名存实亡了。）

X出了什么问题？

X的罪过就是，因为他是X。如果想做一个X服务器，就必须支持海量的功能，否则就不能说遵守X协议，而这些功能不会有任何人还在用。比如core fonts，这个是X11刚出现的那些年做的最原始的字体模型用于在屏幕上显示文字。他包含代码表、字形栅格化、缓存和X逻辑字体描述（不可思议！）而且，这个核心渲染API还能让你画连点线、多边形、圆弧和各种各样20世纪80年代的复古图形。我们是可以用很多插件比如XRandR、XRender和X合成器来保持Xorg服务器足够现代来逐渐淘汰那些用处不大的插件，但是我们却完全不能摆脱核心的渲染API和那些现代桌面很难用到的复杂玩意。有了Wayland我们就能把X服务器和那一帮过时的技术丢到一个可选的代码目录去了。

在Wayland中运行X的性能消耗?

几乎所有的现代桌面都已经开始用一个外置的合成管理器：当X服务器准备更新绘图内容时，他通知这个进程（一般也是你的窗口管理器）（译注：也有的窗口管理器和合成管理器是两个程序），让他来完整的操纵合成的过程。用Xwayland差不多也是这个过程，但是效率更高，因为这里的合成管理器不需要把他渲染的内容再返还给X服务器了。

Wayland能穿透网络吗 / 他支持远程显示吗？

不，这超出了Wayland设计的目标。想要支持远程显示你需要定义一个渲染API，是我一直谨慎回避的事情（译注：已经多次提到，Wayland的各个应用程序应该自己渲染自己的内容，而不是用一个统一的渲染API）。Wayland能做得如此简洁可用的原因，完全是因为我把所有难做的事情都推给客户端自己完成。这是个挺有意思的挑战，一个巨大的任务而且不太容易做好，但是基本正交的结构就是Wayland想做到的事情。

这不意味着用Wayland就无法实现远程显示，只是你必须要再在Wayland上层加一个远程显示服务器。这样的服务器可以是Xorg服务器，但是更多的选项可以是RDP服务器、VNC服务器或者将来会有某些人开发的新远程渲染模型的服务器。再思考一下，你会发现这其实是一个优点，因为在Wayland上叠加一个Xorg消耗资源不大，而其他的远程显示服务器又不再依赖Xorg，体验新的远程显示协议会变得更加容易。

可以把远程显示协议内置到Wayland合成器中，可以做一个独立的远程显示合成器，也可以作为完整的桌面合成器的一部分。这就能帮助我们转送原生Wayland应用。独立版的合成器能让你登录到服务器电脑中，运行应用程序显示到你的桌面。整合了转送功能的桌面合成器可以让你导出或共享一个窗口到一个远程Wayland合成器中，比如说到一个朋友的桌面上。

2020年时，有一些工程采用了这些方法去让远程计算机使用GUI。Weston合成器提供了一个RDP后端。GNOME有一个支持VNC的远程桌面服务器（原文）。WayVNC（原文）是一个可以用在基于wlroots的合成器的VNC服务器，比如Sway（原文）。Waypipe（原文）能用在所有Wayland合成器上，提供一个几乎穿透的应用转送，就像 ssh -X一样。

怎样下载和构建Wayland？

参见构建指导（原文）。

为什么不用D-Bus作为Wayland的IPC机制？

我想保留X协议中的一些重要性质：队列一个事件和请求而只需要把内存复制（memcpy）到外置缓冲区的能力。这就是wl_connection_write做的事情。此外，他也能让我们内存复制一些信息到缓冲区，而只需要在主事件循环的阻塞阶段开始之前完成写入。再次，一切都是明确异步的，这是这个协议中一个真正强大的优势。

我怎么才能换掉Wayland的窗口管理器？

（译注：早期有人会认为Weston是一个类似Xorg的服务器，所以会有这样的问题）

Wayland架构中把显示服务器、窗口管理器和合成器都融合成了一个进程。你可以把Wayland看作一个工具包来创建各种客户端和合成器。他不是一个特定的合成器或者窗口管理器。如果你想要一个不一样的窗口管理器，你可以编写一个新的。有一个名为libweston的库正在努力让新的桌面环境能重复使用Weston的代码库和机制，同时使用他们自己的外观和用户体验。

为什么Wayland选用EGL？

（译注：Wayland使用EGL实现共享缓冲区，来让客户端和合成器交换数据。）

EGL是一个唯一的GL接合（binding）API能避免依赖已有的窗口系统，尤其是X。GLX明显是把X作为依赖项，而且只允许我们在X的可绘制区域（drawable）中使用GL。要么我们就得来做一个Wayland专用的GL接合API，该叫什么，WaylandGL。

一个更隐晦的问题是libGL.so包括了GLX符号（symbol）（译注：链接动态库时需要读取的一些内容），所以一旦链接这个库就会引入所有X的依赖项。所以我们不引入X客户部分就不能链接到完整版的GL，因此Weston选择OpenGL ES来渲染。这也能让Weston能在一些不支持使用完整版OpenGL API的GPU上运行。

我们之前也说过了，Wayland的客户端可以随便用各种他们喜欢的渲染API。