揭开Wayland的面纱(二):Wayland应运而生

话说在上篇(揭开Wayland的面纱(一):X Window的前生今世)中我介绍了一些X Window的历史及发展,还没有提到Wayland本身,不少人已经等不及了。不过,介绍这些是有必要的,毕竟要知道X Window的一些知识,才能明白为什么会有Wayland这个东西。

在本篇正式开始介绍Wayland之前,让我们先回到2008年11月4日,也就是整整两年前,我当时在中文领域第一时间报道了"Wayland"的新闻:[Wayland:Linux的新X Server](http://www.ibentu.org/2008/11/04/linux-new-x-server-

waylan.html),在其后的一个月,又写了:[Wayland最新动态](http://www.ibentu.org/2008/12/09

/wayland-news.html)。

当时这两篇文章主要是翻译Phoronix的新闻,自己也没有亲自把玩过Wayland,再加上Wayland项目还处于比较初期的阶段,对其的理解有限。如今经过整整两年的开发,包括Linux内核在图形方面的不断的改进、GTK+图形库的不断进化,Wayland已经渐渐成熟,接近可用状态。

那么,回到上篇开头最初的那个问题:

Wayland究竟是什么?

如果在两年前,按照那篇《[Wayland:Linux的新X Server](http://www.ibentu.org/2008/11/04/linux-

new-x-server-waylan.html)》的理解,它是一个新的"X Server",在于改善当前X Server的不足,从而取代它。现在,我们已经可以用更标准的语言来定义Wayland了,那就是:A Simple Display Server。

没错,Wayland是一个简单的"显示服务器"(Display Server),与X Window属于同一级的事物,而不是仅仅作为X Window下X Server的替代(注:X Window下分X Server和X Client)。也就是说,Wayland不仅仅是要完全取代X Window,而且它将颠覆Linux桌面上X Client/X Server的概念,以后将没有所谓的"X Client"了,而是"Wayland Client"。

更确切的说,Wayland只是一个协议(Protocol),就像X Window当前的协议---- X11一样,它只定义了如何与内核通讯、如何与Client通讯,具体的策略,依然是交给开发者自己。所以Wayland依然是贯彻"提供机制,而非策略"的Unix程序。

"什么?Wayland还是Server/Client模式?"可以这么理解,但实际上与X Window的Server/Client有着本质的区别。

让我们用一张类似前文所示的图表来重新演示一下,在Wayland的框架下,窗口事件的响应是如何进行的。

在Wayland的架构图中,最显著的一些特点是:

  • 它复用了所有Linux内核的图形、输入输出技术:KMS、evdev,因此已支持的驱动可以直接拿来用;
  • Wayland没有传统的Server/Client的模式,取而代之的是:Compositor/Client,这不仅仅是换一个名称而已,后面会讲到具体区别;

[Wayland
Architecture](/media/uploads/2010/11/wayland-

architecture.png)

还记得前文中"点击Firefox的刷新按钮"这个应用场景吧?在Wayland里,所有的流程是这样的:

  1. 内核收到了鼠标发出的信息,经过处理后转发到了Wayland Compositor,就像之前发往X Server一样。
  2. Compositor收到消息后,立马能知道哪个窗口该收到这个消息,因为它就是总控制中心,它掌握窗口的层级关系、动画效果,因此它知道该坐标产生的鼠标点击信息应该发送给谁,就这样,Compositor将鼠标的点击信息发送给了Firefox。
  3. Firefox收到了消息,这时如果是在X Window下的话,Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里,Firefox可以自行进行绘制而不需要再请求Compositor的许可!这就是传说中的:直接渲染机制(Direct Render)!Wayland不管Client的绘制工作,整个过程变得十分简单而且高效!当Firefox自行完成了按钮状态的绘制后,它只需要通知Compositor,某块区域已经被更新了。
  4. Compositor收到Firefox发来的信息的,再重新合成那块更新的那块区域,将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。

整个流程是不是很自然、很简单?

所以结论出来了:

  1. Wayland的"直接渲染架构"彻底结束了传统X Window在渲染图形时需要不停的向Server请求、确认再绘制这个繁琐的过程,理论上响应速度有了"爆发式"增长;
  2. Wayland从根本上消除了"Server+Compositor"的重复劳动,仅有且只需要有一个"Compositor"合成器而已。

Compostior,就是Wayland上的"X Server",但是它更纯粹,它不像X Server一样,像个大家长,什么都要管。Compositor只做该做的事情,把上面的过程简化成任务便是:

  1. 基于Wayland协议,处理evdev的信息;
  2. 通知Client(即应用程序)对相关事件做出反应(至于应用程序想怎么反应,Compositor不需要过问);
  3. 收到Client的状态更新,重新合成图形或管理新的图形布局。

你意识到了,Wayland Compositor的角色,就像是"X Server"+"Window Manager",但它只做份内的事情而已。我想你已经可以想像Wayland构架是如何简单而且高效了,它一举解决了"X Window"发展这么多年来积累的、通过"扩展"去解决的那些问题。

看似很美好,那么Wayland现在的可用性如何?大家都知道,GTK+、Qt,现在都是基于X的,它们能顺利地移植至基于Wayland吗?当然可以!

逐渐成熟的Wayland周边应用

还记得前面那篇文章中,我说过的这句话吧:"尽管在Linux平台下,Cairo、Pango的发挥依然是基于X Window的,但X Window充其量仅仅是一个"backend"而已,并不是少它不行。同理,跨平台的GTK+、Qt也只是视X为其中所支持的后端之一,假如哪天X真的 不在了,更换一个新后端,当前的GNOME、KDE也能完整的跑起来。"

你已经想到了,GTK+、Qt,只需要简单的处理一下后端,便可以跑在Wayland上了。比如:

在当前的GTK+3.0开发分支中,有一个开发分支是"[rendering- cleanup](http://git.gnome.org/browse/gtk+/log/?h=rendering-

cleanup)"。"清理渲染"?这是做什么的?联想一下那个连Client"怎么渲染"都要管的X Server吧。

对了!GTK+3.0已经彻底移除了所有图形渲染、绘图方面跟X相关的部分了,现在它是一个100%基于Cairo绘制的图形工具库了(之前GTK+2.x时在2.8开始逐渐转向用Cairo绘制,但一直不彻底)。

这意味着两点:

  • GTK+的一直以来评价不怎么样的跨平台性,在3.0将有显著的突破;
  • GTK+的Wayland后端,已经在路上了!

见GTK+跑在Wayland上,截图引自:Kristian Shows Off GTK+ 3.0 On Wayland

Wayland and GTK+

当然,Qt也有了,限于篇福,这里就不介绍了。

另外一个已经在主开发分支便支持Wayland的东西便是:Clutter。这是一个基于OpenGL的动画框架,我以前介绍过很多次的[GNOME Shell](http://imtx.me/tag/gnome-

shell/)、[Moblin](http://www.ibentu.org/2009/07/10/moblin-2-0-beta-

media.html),都是基于Clutter的。在Clutter当前1.5.x的开发分支,Wayland作为其中一个"backend",已经得到了"experimental"的支持。所以说,GNOME 3.0、MeeGo Netbook很可能会成为第一个应用Wayland的桌面环境。

那么,看来Wayland真的触手可及了啰?可以这么说,但是还差一点。

Wayland技术实现及工作重点

Wayland的核心协议已经实现的差不多了,它充分利用了Linux内核的KMS、GEM、DRM等技术,另外,它默认是支持3D加速的,也就是通过OpenGL ES进行图形的合成----光是这一点,X Window又要泪奔了。

使用OpenGL ES这个子集而非OpenGL,这意味着什么?想想有多少项目是用OpenGL ES的:Android、iOS、WebOS、WebGL……几乎所有主流的的移动操作系统、浏览器3D的实现,都选用了精简、高效的OpenGL ES。

我不知道当前Android的Display Server、Input/Output是如何实现的,总之跟iOS相比,在触控的响应上是有差距的。未来,对OpenGL ES有着良好支持的Wayland,不知道会不会给这些基于Linux内核的移动操作系统发力呢?我想是非常有可能的!

这时问题就来了,因为Wayland所使用的,都是当前Linux下最新潮的图形技术。所以理所当然的,在驱动这一层面会有一些厂商跟不上。

拿nVIDIA开刷吧,KMS技术都出来一年多了,Intel的全部显卡和AMD部分显卡已经获得支持了,可nVIDIA压根就没有兴趣搞这个,以致于开源社区利用反向工程,通过"Nouveau"项目让nVIDIA支持了KMS,当然比较遗憾的是,性能跟官方闭源的驱动是差了相当的距离。

所以说,基于Wayland的Linux桌面/移动要真正得到应用,驱动这一关是一定要解决的。不过正所谓潮流不可挡,nVIDIA迟早会支持这项技术的。

等到驱动完全不成问题了,Wayland还需要一个全功能的"Compositor",这个角色,就由Clutter/Mutter、Compiz、KWin等当前主流的窗口管理器来扮演的,相信只要通过简单的修改,这些合成窗口管理器很快地就能转变成一个全能的"Wayland Compositor"!

把玩Wayland及展望未来

讲了这么多技术、历史和业界,大家肯定枯燥了,究竟现在有没有可以跑的"Wayland Compositor"可以玩玩呢?当然!

现在,只要你从官方取得源码,然后根据教程进行编译,就能跑起一个简单实现的"Wayland Compositor"。由于Wayland协议的灵活性,Wayland Compositor也可以拥有自己的后端:比如直接在DRM上跑Wayland(不需要X),或者在X Window上跑起一个Wayland Compositor(相当于在X Window上用Xephyr再跑一个X Window)。

当前我在Ubuntu 10.10的图形环境下,就跑起了默认的这个简易的Wayland Compositor,几点说明:

  • 支持透明、阴影和简单的窗口管理;
  • 所有的图形绘制,都是通过Cairo-gl(Cairo的OpenGL后端)进行;

[Wayland Terminal](/media/uploads/2010/11/wayland-picture-and-

drag-drop.png)

这是又一个例子,我编译了Clutter的Wayland后端,成功地跑起了一个Clutter的Demo:即同中Ubuntu Tweak的3D Logo。

Wayland and
Clutter

除了这个Wayland Compositor本身是跑在X Window之上,其本身合成效果、处理窗口布局等等,都完全没有用到X,而且整个代码非常简洁。未来的Linux图形,就会像是这样一个结构简单又高效的样子。

相信看完我这些介绍,大家对Wayland是个什么角色,已经比较清楚了吧?

简单的说,它就是一个去除X Window中不必要的设计、充分利用现代Linux内核图形技术的一个显示机制,它的出现是自然而然的,它的使命不是为了消灭X Window,而是将Linux的图形技术发挥至更高的一个境界。传统的X Window(即经典X应用、Gtk 1.x/2.x等旧应用),也会在相当长一段时间内得到继续支持,通过Wayland Client的形式跑在Wayland Compositor上,直到最终升级、取代或被淘汰。

2011年后期或2012年,我们将能看到Wayland正式着陆,期待吧!

<推广> 本站架设于 Linode 东京机房,同时使用 云梯 进行科学上网

34 Comments

  1. 看起来真的很不错,期待啦。算的上革命吗?

  2. 不错,虽然这方面不太懂,但是看了一遍后基本就了解了。不过把WM集中进去的话应该会有些问题,至少当前的一些程序如果了利用不同的WM写代码,到时候就会有兼容性的问题。

  3. 主席,真是厉害写了那么多,先顶再看~

  4. 主席啊 ,Wayland Compositor 没意思,

    DRM 上的 Wayland 才好哎

  5. Hexchain

    我看到文章就去编译 Wayland 去了……

  6. 主席啊!所有闭源驱动都不支持 KMS 的啊!包括 AMD 和 NVIDIA。

  7. 有些地方没看明白:
    1. wayland的compositor是否取代了现有的wm的窗口管理部分功能?如果是,感觉不是简单而是更复杂了,wm本身就是策略而非机制。另外让那些喜欢平铺式窗口人情何以堪啊?
    2. wayland比X所精减的关键性东西是什么?目前理解是减少了重复的渲染工作交互。至于窗口的管理,我的理解是在X里,wm只负责toplevel窗口的摆放,而内部子窗口的位置是由ui框架(负责子窗口与toplevel窗口的相对位置)和X(通过相对坐标计算子窗口的绝对坐标)共同完成的。wayland在这一部分有何改变?
    3. 对比两个架构图,我觉得wayland好像就是把X server和compositor合并了,然后去掉重复的东西

    • 我的理解,wayland把部分工作交给firefox这类程序去做了,或者是允许firefox去做,而不用再让X去做,就像很多时候系统卡,都是X这个进程卡,但是你又不知道是什么程序导致X卡。

    • 我的理解是 Wayland 似乎只是提供了现有 WM 中的 compositor 功能,而具体怎么利用 compositor 来实现一些功能和动画效果还是 WM 来做的。另外 Wayland 本身协议和 X 的不同,不能简单理解为把 X server 和 compositor 合并了。

  8. ltn

    一开始我还担心我们喜欢的窗口管理器窗口管理器再也用不上了呢,现在看来,应该不至于

  9. thorne

    土人表示没有认真读懂 纯围观

  10. wayland的设计太激动人心了。

  11. socekin

    主席,我来学习了,不过似懂非懂。我能转载不?

  12. 主席,我表示我看懂了~皮毛

  13. Shine Cue

    为什么这里和iBentu是同步的?我只好删掉iBentu的RSS了。

  14. Voidprayer

    一帮不睡覺的……
    看,我早起吃蟲了。

  15. HelloWorld

    不好意思,哪位能写一篇文章,介绍一下NVIDIA和AMD显卡开源驱动的进度?我有点关心这个问题。

  16. Xephyr很給力..當初調教awesome有很大功勞

  17. Wayland很给力,我看好它。
    到时Linux桌面响应速度应该也必须提升不少吧!

  18. tlze

    使人兴奋的新技术,谢谢大侠精彩的文章。

  19. linyuzong

    编译成功wayland,在终端上运行compositor,但什么也没有,如何运行xterm等

  20. linyuzong

    请问主席,如何运行termiral

  21. linyuzong

    就是方便打开一个新的虚拟终端

  22. 好文,又长新知识了。
    只是不知道原来现在linux对ATI支持原来比nVidia好...我还以为ATI还停留在原来的放电影闪屏年代呢。正在考虑换显卡。

  23. 很精彩,未来Linux开始在桌面发力!

  24. 又一强大的神器。。

  25. 说的这么好听,可是 MacOSX早就是这个构架了啊 .......

    • Pepino

      所以现在要跟上,Windows从Vista起也是类似的构架

      • Lynx

        这么说Windows特效效率应该比Linux高很多?按照本文的说法。
        实际上,我家那个CPU Althon 3600+ 显卡 NVIDIA Geforce 6100 内存 1G的烂机子跑Gnome和KDE的立方体都毫无压力,不论是flip还是slide show也都很顺畅。// fps 在20以上
        跑Windows Vista和 Windows 7的flip反倒是压力很大。 //fps目测从没超过20,并且经常看得出不超过10
        真搞不懂。
        一直以为Mac用的X Window。这方面看来是我sb了。求教,Mac到底用的是神马?

  26. dyboy

    是啊,xwindow 多余的设计该去除了,特别是颜色管理,别扭的使用了colormap,
    我推荐一个直接的使用颜色方案,

Leave a Comment