为什么Wayland更好?


177

正如Mark Shuttleworth 最近宣布的那样,Ubuntu将逐步使用Wayland作为其显示管理器。

X11和Wayland之间最大的区别是什么?为什么Wayland会让Ubuntu更好?


5
从2013年12月开始,基于Unity的Ubuntu似乎将使用Mir显示服务器,而不是从Ubuntu 14.10开始使用基于Wayland的合成器:链接 链接其他Ubuntu变体可能会移至Wayland:链接
Diego

4
这是一段精彩的视频,解释X以及人们为什么要替换它:youtube.com/watch?v=cQoQE_HDG8g
Jason

Ubuntu 18(Bionic)现在默认情况下将使用xorg,但在登录屏幕上仍然可以选择wayland
Kris,

我会说X更好。我不会讲技术的东西。但我只想说如果我调整窗口大小或全屏进入/退出屏幕,我会在YouTube和Wayland上放帧。使用X,没有问题。即使速度相同。同样在Wayland上,鼠标指针比X上的鼠标更松动。X仍然是我的头号人物
Luka,

Answers:


136

您可以查看Wayland体系结构页面,以了解其设计差异。通过将所有内容强制通过标准GEM / DRM堆栈直接进入内核并管理合成本身,可以简化整个图形堆栈。

将其与X堆栈进行比较,在X堆栈中到处都是点滴。有些X混乱是通过灵活的设计实现的,有些则变得越来越麻烦。后来,所有合成器(Compiz / Metacity / Mutter / KWin / etc)都被添加了。他们的核心是黑客,他们可以做X应该做的事情。如果事情像往常一样继续向外扩展,我们将达到项目无法维护的地步。

总而言之,只要有硬件支持,它就可以使整个堆栈更高效,在标准设置中使用时也不会那么痛苦。

但是,到目前为止,有几个问题我还没有看到补救措施:

  • X非常了解网络。您可以将窗口发送到其他计算机,也可以具有多个屏幕,这些屏幕具有远程登录名和类似的各种时髦内容。这看似相当专业,但却是被广泛使用的技术。与之相比,Wayland显得相当局部和静态。

  • 还有驱动程序支持。开源驱动程序尚未支持Wayland赖以生存的KMS / shared-GEM / shared-DRM技术。纯粹主义者对Nouveau可能还可以,但是有人花100-400英镑购买了高性能3D图形卡,他们不会对使用当前开放驱动程序时会出现的片状差3D性能感到满意。

    更新: Nvidia正在努力支持Wayland和Mir


2018更新。17.10使用Wayland作为默认显示服务器(除非您有封闭的驱动程序,或者不支持它的驱动程序,或者需要X)。18.04和18.10都使用X作为全局默认值(尽管您可以安装Wayland)。

除了这个职位,我什么都不做,似乎我们仍然是Nvidia的标准,无法获得真正的吸引力。在此之前,我认为我们不会看到足够的头脑份额和发展实力落后于Wayland。游戏/表演市场使用X。MCE市场使用X(和直接帧缓冲器)。我不确定Wayland是否会真正有机会。


21
网络透明性被过分夸大的原因有几个。1.纯X转发仅在LAN上足够快。在Internet上,由于延迟,原始X无法使用。要获得良好的性能,您必须使用第三方协议,例如NX或VNC。2.由于X的体系结构,NX和VNC都很难设置。Wayland应该更容易。3.很少有现代工具箱使用X的绘图代码。他们只是将自己绘制到位图上并将其发送到X。这与Wayland完全相同,并且具有相同的网络特性。
Timmmm 2012年

4
我同意第1点,但是在良好的LAN上,X转发对于质量或性能来说是不可改变的。根据我的经验,这比任何一种选择都要好得多。
奥利

1
截至2013年,有关网络透明性的情况更加清晰:askubuntu.com/a/359870/203271
Diego

2
@poolie:似乎他们改变了主意。;-)
Peque 2015年

2
来自BionicBeaver / ReleaseNotes:“ X是默认的显示服务器。Wayland作为技术预览提供,并且有望成为20.04 LTS中的默认显示服务器。要尝试,只需从登录上的齿轮选择Wayland上的Ubuntu屏幕上,现在可以在〜/ .local / share / xorg中找到X.org日志。[[重点]
Dennis Williamson

56

X和Wayland之间有很多差异。从图形方面来看,最大的大概是Wayland 不做任何绘图

X有两个绘图API。其中之一是X11核心协议的一部分,该协议是古老的,无用的并且没有人使用。另一个是XRender扩展程序,它提供了现代的合成操作,例如渐变。例如,这就是开罗的用途。X还具有字体绘制API。

Wayland没有绘图API。Wayland客户端获得DRM缓冲区句柄,该句柄基本上是指向某些图形内存的指针。Wayland不知道或不在乎客户端如何吸引该缓冲区。用X术语,这意味着所有应用程序都可以直接渲染 -绘图请求不需要通过服务器。

Wayland唯一的渲染方法是将客户端的缓冲区复制到屏幕上。

就收益而言,Wayland的复杂度要比X小得多,这应该使维护更容易-尽管其中的一些简化来自将复杂性(例如:如何实际利用该缓冲区,网络透明性)推到了X的其他层次。堆。通过让客户端负责所有渲染,客户端可以更聪明地处理诸如双缓冲之类的事情。

图形之外还有其他好处。例如,使用沙盒应用程序要容易得多。


2
听起来像微软的DirectX之类的东西?
安瓦尔

3
我使用核心的X11协议绘图API,因为它比XRender更快。
étale-上同调

3
我也可以通过Wayland和systemd获得Microsoft wibes。不,那不是一件好事。他们违反了基本的软件开发规则。在systemd中,仅仅是因为它对systemd的开发人员来说更容易。在Wayland中,因为他们想要更快的游戏(?)和渲染速度,并因此抛出很多好东西。
安德斯(Anders)'18

18

我眼中的主要区别是Wayland比X-Server更接近内核。随着图形驱动程序从X移到内核(称为内核模式设置,KMS),Wayland计划使用此新功能来替换X。您可能会看到以下信息...

占用空间比X少-因为显示是由内核Wayland处理的,因此不必为实现可用而进行过多的实现。这是双向的,因为我怀疑X转发(看另一台PC上的一个屏幕)可能会随着X消失。

KMS功能:无需重新启动X服务器即可更改屏幕分辨率(尽管我相信这已经在X上修复了,至少对于nvidia而言已解决),如果您愿意,可以在内核恐慌的情况下针对英特尔芯片组调试控制台(移至nouveau)。之类的东西。

如果我错了,有人可以纠正我吗?


4
KMS&GEM不会将图形驱动程序移至内核,只有一些小部分移至内核(这些位直接与硬件对话,并且需要位于内核中,以便不同的驱动程序可以共存,例如写入I / O端口并管理内存)。X现在已经使用KMS和GEM,至少将其用于现代开源驱动程序(intel,radeon,nouveau)。顺便说一句:我非常怀疑将整个图形驱动程序移至内核是否会被Linus接受...;)
JanC

4
哦,KMS从来不需要更改屏幕分辨率(自从我十多年前使用X以来,这是有可能的),但是它允许使用不同的驱动程序(例如,控制台帧缓冲驱动程序,X驱动程序以及现在的Wayland驱动程序)更轻松地合作。过去,对于每个硬件而言,在特定时间点处于什么“状态”并不总是很明显,因此使用了很多猜测或依赖于驱动程序的专有解决方法。
2010年

1
因为X仍然可以用作Wayland的客户端,所以X转发将消失并不完全是真的。wayland.freedesktop.org就是一个例子。但是无论如何,X是一种相当可怕的方式。现在该更换它了。在许多情况下,将GTK与Broadway结合使用似乎是一种更好的方法。
Jo-Erlend Schinstad 2011年

3
RandR扩展允许您更改屏幕分辨率而无需重新启动X服务器。
匿名

14

所有其他文章都强调了Wayland的好处,但这不仅是一件好事。X与Wayland相比,最大的优点是X通过网络工作。X是网络透明的,您可以在实际程序在另一台通常功能更强大的计算机上运行时,在终端上显示窗口或使用XDMCP完整会话。像Wayland这样的东西,网络透明性的想法就消失了。如今,对于快速的网络以及诸如VNC和RDP之类的其他协议,可能并不需要那么多,只是出于完整性的考虑。


这正是我也认为X优于拟定Wayland的最大优势。
克里斯·杰斯

7

简而言之,希望有更好的图形(更少的错误,更快,更易于使用)。甚至有一天可能会发生以前没有的事情。我个人认为,这至少会像往常一样使事情变得有趣。


3

任何人在日常工作中都会很快注意到的两件事:

  • Wayland取消了在X11中难以修复的剪纸。一个著名的例子:在打开菜单或打开锁定屏幕时使用功能键(扬声器音量,显示屏亮度等)。
  • Wayland在输入设备方面表现更好。首先,还有更多用于配置触摸板的选项,包括持久的点击式设置。

1
如果程序由于某种原因被锁定,Wayland会更糟。拥有不同的wm是一件好事。我定期(每天)使用网络X11。某些程序已停止在Wayland中工作(我使用Ubuntu 18.04)
Anders
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.