Lighthouse 直到前段时间还没有的一个特性是它没有提供在服务器和客户端同时运行Qt时的多进程的解决方案，这对于嵌入式设备是很重要的。虽然现在Qt当中有 QWS（开发嵌入式Qt程序时使用的一个窗口系统，类似X Windows的C/S结构，从而保证Qt程序的的可移植性）。但是QWS并不是一个正式的协议，从而使得QWS的服务器和客户端是紧密耦合的。
因此如果有一个现成的协议可以利用的话，就会省下Qt开发者的不少功夫，然后他们最终发现Wayland（严格说来Wayland也是一个协议）正是他们所需要的。
在过去的几个月里Qt的几名开发者都在研究Wayland，然后他创建了一个新的实验室项目Qt-Compositor，这个项目的目标是作为一个基础层让其他人完成他们自己的Wayland compositor。Qt-Compositor抽象了所有Wayland Compositor所需要的通信。
其实我想很多人关心的重点其实就是Qt现在也有一个可以demo下的Wayland支持啦。虽然开发者们更多提到的是嵌入式系统，大概也就是想让Lighthouse替代以前的QWS，Wayland在Qt嵌入式的下一步也有着重要的作用。
#p#
Lighthouse在去年10月底的时候决定和Qt的master合并，评论里面不少人其实在催xcb支持（X的c语言绑定），后面也回复有xcb现在也正在开发中。lighthouse看来将成为Qt的移植性/跨平台的下一步。
基于UIKit的验证概念的新Lighthouse平台
也许没有Android移植那样令人兴奋(但也许会比新的INTEGRITY平台更加振奋人心，至少对于我是这样的 )，我刚刚将一个新的概念验证性的、基于UIKit的Lighthouse插件实现提交到qt-lighthouse代码仓库中。
这意味着，如果您仔细地遵照附带的README文件中的使用说明(在qt-lighthouse代码仓库中的src/plugins/platforms/uikit/中)，您应该可以能够针对iOS模拟器和设备目标构建(部分)Qt，并且运行一些简单的Qt Quick应用程序。我不得不强调，这不是一个真正的iOS移植，并且也不会以任何方式被支持。很有可能Qt的很多部分都不工作，甚至这些部分都不能编译，更不用提那些我甚至都没有试图编译的部分。
即便如此，鉴于QML技术如此之酷，这个小项目的目标就是让一些简单的QML应用程序可以运行在iPhone上， 以检验Lighthouse在技术上是否可以完成这个任务。
编译和链接Qt(然后它可以真正地运行)
这个过程绝对是最冗长的部分，而且需要心理足够强大能够承受巨大的挫折。我面对过很多问题，例如抱怨一些处理器指令不可用等链接错误，以及在代码运行时方法返回值和变量突然改变或者归零等，直到后来我发现是底层mac平台gcc的mkspec设置了桌面相关的环境变量， 扰乱了iOS部分。将这部分修正得差不多正确了之后，因为iOS基本上是一个POSIX平台，所以大部分编译和链接“能直接工作”。
Lighthouse平台插件
我采用了一个比较容易的路径，就是Cocoa平台插件实例中所做的，例如在UIView中显示(blip)QImage。当然这不是最有效率的方式(因为在运行QML的flickr演示程序的时候就可以很容易地看到这一点)，但是和我们的快速概念验证的目的很适合。尽管还有一些挑战，例如在集成事件循环时，如果一个iOS应用程序没有尽快调用UIApplicationMain就会导致它会被系统杀死。
#p#
Wayland究竟是什么？
如果在两年前，它是一个新的“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，这不仅仅是换一个名称而已，后面会讲到具体区别；
还记得前文中“点击Firefox的刷新按钮”这个应用场景吧？在Wayland里，所有的流程是这样的：
内核收到了鼠标发出的信息，经过处理后转发到了Wayland Compositor，就像之前发往X Server一样。
Compositor收到消息后，立马能知道哪个窗口该收到这个消息，因为它就是总控制中心，它掌握窗口的层级关系、动画效果，因此它知道该坐标产生的鼠标点击信息应该发送给谁，就这样，Compositor将鼠标的点击信息发送给了Firefox。
Firefox收到了消息，这时如果是在X Window下的话，Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里，Firefox可以自行进行绘制而不需要再请求Compositor的许可！这就是传说 中的：直接渲染机制（Direct Render）！Wayland不管Client的绘制工作，整个过程变得十分简单而且高效！当Firefox自行完成了按钮状态的绘制后，它只需要通知 Compositor，某块区域已经被更新了。
Compositor收到Firefox发来的信息的，再重新合成那块更新的那块区域，将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。
整个流程是不是很自然、很简单？
所以结论出来了：
Wayland的“直接渲染架构”彻底结束了传统X Window在渲染图形时需要不停的向Server请求、确认再绘制这个繁琐的过程，理论上响应速度有了“爆发式”增长；
Wayland从根本上消除了“Server+Compositor”的重复劳动，仅有且只需要有一个“Compositor”合成器而已。
Compostior，就是Wayland上的“X Server”，但是它更纯粹，它不像X Server一样，像个大家长，什么都要管。Compositor只做该做的事情，把上面的过程简化成任务便是：
基于Wayland协议，处理evdev的信息；
通知Client（即应用程序）对相关事件做出反应（至于应用程序想怎么反应，Compositor不需要过问）；
收到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+、Ｑt也只是视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+的一直以来评价不怎么样的跨平台性，在3.0将有显著的突破；
GTK+的Wayland后端，已经在路上了！
见GTK+跑在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，几点说明：
支持透明、阴影和简单的窗口管理；
所有的图形绘制，都是通过Cairo-gl（Cairo的OpenGL后端）进行；
这是又一个例子，我编译了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上，直到最终升级、取代或被淘汰。
来源：
http://labs.qt.nokia.com/2011/03/18/multi-process-lighthouse/
关于wayland的介绍，我就扔两篇tualatriX的blog了做参考了：
http://imtx.me/archives/1573.html
http://imtx.me/archives/1574.html
【编辑推荐】
