话说在上篇(揭开Wayland的面纱(一):X Window的前生今世)中我介绍了一些X Window的历史及发展,还没有提到Wayland本身,不少人已经等不及了。不过,介绍这些是有必要的,毕竟要知道X Window的一些知识,才能明白为什么会有Wayland这个东西。 Wayland究竟是什么? 如果在两年前,按照那篇《Wayland:Linux的新X Server》的理解,它是一个新的“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的架构图中,最显著的一些特点是:
还记得前文中“点击Firefox的刷新按钮”这个应用场景吧?在Wayland里,所有的流程是这样的:
整个流程是不是很自然、很简单? 所以结论出来了:
Compostior,就是Wayland上的“X Server”,但是它更纯粹,它不像X Server一样,像个大家长,什么都要管。Compositor只做该做的事情,把上面的过程简化成任务便是:
你意识到了,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”。“清理渲染”?这是做什么的?联想一下那个连Client“怎么渲染”都要管的X Server吧。 对了!GTK+3.0已经彻底移除了所有图形渲染、绘图方面跟X相关的部分了,现在它是一个100%基于Cairo绘制的图形工具库了(之前GTK+2.x时在2.8开始逐渐转向用Cairo绘制,但一直不彻底)。 这意味着两点:
见GTK+跑在Wayland上,截图引自:Kristian Shows Off GTK+ 3.0 On Wayland 当然,Qt也有了,限于篇福,这里就不介绍了。 另外一个已经在主开发分支便支持Wayland的东西便是:Clutter。这是一个基于OpenGL的动画框架,我以前介绍过很多次的GNOME Shell、Moblin, 都是基于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,几点说明:
这是又一个例子,我编译了Clutter的Wayland后端,成功地跑起了一个Clutter的Demo:即同中Ubuntu Tweak的3D Logo。 除了这个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正式着陆,期待吧! |