Oli*_*Oli 154
您可以查看Wayland 架构页面以了解它在设计上的不同之处。它应该通过强制所有内容通过标准 GEM/DRM 堆栈直接进入内核并管理合成本身来简化整个图形堆栈。
将其与 X 堆栈进行比较，在那里您到处都有点点滴滴。一些 X 混乱已经通过灵活的设计，一些已经成长的烦恼。所有的合成器（Compiz/Metacity/Mutter/KWin/etc）都是在事后添加的。它们的核心是黑客来做 X 可能应该做的事情。如果事情像以前一样继续向外扩展，我们将达到项目无法维护的地步。
总而言之，当有硬件支持时，它应该使整个堆栈在标准设置中使用时更高效且痛苦更少。
但是，到目前为止，我还没有看到一些补救措施：
X 非常了解网络。您可以将窗口发送到其他计算机，您可以拥有多个带有远程登录的屏幕以及诸如此类的各种时髦的东西。这可能看起来相当专业，但它是广泛使用的技术。相比之下，Wayland 显得相当本地化和静态。
还有驱动程序支持。闭源驱动程序尚未支持 Wayland 赖以生存的 KMS/shared-GEM/shared-DRM 技术。纯粹主义者可能对 Nouveau 没问题，但在高性能 3D 显卡上支付 100-400 英镑的人不会对他们使用当前开放驱动程序获得的片状 3D 性能感到满意。
2018 更新。17.10 使用 Wayland 作为默认显示服务器（除非你有一个封闭的驱动程序，或者一个不支持它的驱动程序，或者需要 X）。18.04 和 18.10 都使用 X 作为全局默认值（尽管您可以安装 Wayland）。
我不负责任何事情，但从这个职位来看，我们似乎距离获得真正的吸引力仍然是一个衡量标准的 Nvidia 。在那之前，我认为我们不会看到足够的思想共享和发展力量支持 Wayland。游戏/性能市场正在使用 X。MCE 市场正在使用 X（和直接帧缓冲区）。我不确定韦兰是否会有真正的机会。
RAO*_*AOF 61
X 和 Wayland 之间有很多不同之处。从图形方面来看，最大的可能是 Wayland不做任何绘图。
X 有两个绘图 API。其中之一是核心 X11 协议的一部分，它是古老的、无用的、没有人使用的。另一个是 XRender 扩展，它提供现代复合操作，以及渐变等其他功能。例如，这就是开罗所使用的。X 也有字体绘制 API。
Wayland 没有绘图 API。Wayland 客户端获得一个 DRM 缓冲区句柄，它基本上是一个指向某些图形内存的指针；Wayland 不知道也不关心客户端如何使用该缓冲区。在 X 术语中，这意味着所有应用程序都可以直接呈现——绘图请求不需要通过服务器。
Wayland 所做的唯一渲染是将客户端的缓冲区复制到屏幕上。
就好处而言，Wayland 比 X 复杂得多，这应该使它更容易维护——尽管这种简单性的一部分来自于将复杂性（例如：如何实际绘制该缓冲区，网络透明度）推到其他层堆。通过让客户负责他们的所有渲染，Wayland 使客户可以更聪明地处理双缓冲之类的事情。
除了图形之外还有其他好处。例如，沙盒应用程序要容易得多。
TGM*_*TGM 19
我眼中的主要区别是 Wayland 比 X-Server 更接近内核。随着图形驱动程序从 X 转移到内核（称为内核模式设置，KMS），Wayland 计划使用这个新功能来取代 X。您可能会看到以下内容……
比 X 占用更少的空间 - 因为显示是由内核处理的，Wayland 不需要实现那么多就可以使用。这是双向的，因为我怀疑 X 转发（查看另一台 PC 上的一个屏幕）可能会随着 X 消失。
KMS 功能：能够在不重启 X 服务器的情况下更改屏幕分辨率（虽然我相信这在 X 中已经修复了一段时间，至少对于 nvidia 而言），如果您正在使用英特尔芯片组的内核恐慌调试控制台（转向 nouveau）诸如此类的事情。
如果我错了，有人可以纠正我吗？
Chr*_*jer 17
所有其他帖子都强调了 Wayland 的好处，但不仅如此。X 相对于 Wayland 的最大优势在于 X 在网络上工作。X 是网络透明的，您可以在终端上显示窗口，或使用 XDMCP 显示一个完整的会话，而实际程序在另一台通常更强大的机器上运行。有了像 Wayland 这样的东西，网络透明度的想法就消失了。也许这些天对于快速网络和其他协议（如 VNC 和 RDP）的要求并不高，只是想我会为了完整性而提及它。
在日常工作中，任何人都会很快注意到两件小事：