问题描述
作为Mark Shuttleworth的recently announced，Ubuntu将转而使用Wayland作为其显示器管理器。
X11和Wayland最大的区别是什么？ Wayland为什么要让Ubuntu更好？
最佳解决思路
您可以看到the Wayland architecture page以了解它在设计上的差异。它应该简化整个图形堆栈，方法是通过将标准GEM /DRM堆栈的所有内容直接插入内核并管理合成本身。
将它与X堆栈相比较，你可以在那里找到位和bob。一些X混乱已经通过灵活的设计，一些已经成长的痛苦。所有的合成器(Compiz /Metacity /Mutter /KWin /等)都是在事后添加的。他们的核心是黑客做X应该自己做的事情。如果事情继续像以往一样向外扩展，我们会达到项目无法维持的地步。
总而言之，当有硬件支持时，它应该使整个堆栈在标准设置中使用更加高效并且不那么痛苦。
不过，目前为止我还没有看到几个问题的补救措施：
-
X很漂亮network-aware。您可以将窗口发送到其他计算机，您可以使用多个屏幕进行远程登录以及各种各样的时髦事物。这看起来可能相当专业，但它是广泛使用的技术。 Wayland 看起来相当地方和静态。
-
还有驱动程序支持。 Closed-source驱动程序尚未支持Wayland欣欣向荣的KMS /shared-GEM /shared-DRM技术。对于Nouveau来说，纯粹主义者可能没有问题，但在高性能3D图形卡上支付100-400英镑的人对使用当前开放驱动程序获得的糟糕的3D性能感到不满意。更新：Nvidia is working to support both Wayland and Mir。
无论哪种方式，我们都在谈论多年(可能是2到3个IMO)，然后才能进行稳定的测试，甚至在不得不放弃X之前(如果Wayland显然更好)。
次佳解决思路
X和Wayland有很多不同之处。图形方面最大的一个可能就是Wayland没有做任何绘图。
X有两个绘图API。其中之一是核心X11协议的一部分，这是古老的，无用的，没有人使用。另一个是XRender扩展，它提供了现代组合操作，以及诸如渐变等。例如，开罗就是这样使用的。 X还具有字体绘制API。
Wayland没有绘制API。 Wayland客户端获取DRM缓冲区句柄，该句柄基本上是指向某些图形内存的指针; Wayland不知道或关心客户如何吸引到缓冲区。用X语言来说，这意味着所有的应用程序都可以直接渲染 – 绘图请求不需要通过服务器。
Wayland唯一的渲染就是将客户端的缓冲区复制到屏幕上。
在益处方面，Wayland比X稍微复杂一点，它应该使它更容易维护 – 尽管其中一些简单性来自将复杂性(例如：如何实际绘制到缓冲区，网络透明度)推向其他层叠加。通过让客户对所有渲染负责，客户可以更聪明地了解诸如double-buffering之类的东西。
图形之外还有其他好处。例如，沙箱应用程序要容易得多。
第三种解决思路
我眼中的主要区别在于Wayland比X-Server更接近内核。随着图形驱动程序从X转移到内核(称为内核模式设置，KMS)，Wayland计划使用这个新功能来替换X.您可能期望看到以下内容……
由于显示器由内核处理，因此Wayland将不必实现尽可能多的可用性，因此占用空间小于X.这是双向的，因为我怀疑X转发(查看另一台PC上的一个屏幕)可能会消失X.
KMS功能：能够在不重新启动X服务器的情况下更改屏幕分辨率(尽管我相信这一点在X时代已经修复，至少对于nvidia来说)，调试控制台对于intel芯片组的内核恐慌(转向nouveau)之类的东西。
如果我错了，任何人都可以纠正我的这个问题吗？
第四种思路
简而言之，希望获得更好的图形(减少错误，更快，更易于使用)。即使有一天，事情也许是不可能的。我个人认为这至少会让事情发展起来，就像竞争总是这样。
第五种思路
所有其他帖子都强调了Wayland的好处，但它并不仅仅是好的。 X比Wayland最大的优势在于X可以在网络上运行。 X是网络透明的，你可以在终端上显示窗口，或者用XDMCP一个完整的会话，而实际的程序在另一个通常是更强大的机器上运行。有了Wayland之类的东西，网络透明度的想法就消失了。也许现在对于像VNC和RDP这样的快速网络和其他协议来说，并不是那么需要，只是认为我会提到它的完整性。
第六种思路
day-to-day工作中任何人都会很快注意到的两件小事：
-
Wayland放弃了在X11中被认为难以修复的剪纸。一个着名的例子：当菜单打开或锁定屏幕打开时，使用功能键(扬声器音量，显示屏亮度等)。
-
Wayland在输入设备上更好。首先，配置触摸板的选项还有很多，包括持久的tap-to-click设置。