詳解Qt Lighthouse和Wayland
Lighthouse 直到前段時間還沒有的一個特性是它沒有提供在服務(wù)器和客戶端同時運(yùn)行Qt時的多進(jìn)程的解決方案，這對于嵌入式設(shè)備是很重要的。雖然現(xiàn)在Qt當(dāng)中有 QWS（開發(fā)嵌入式Qt程序時使用的一個窗口系統(tǒng)，類似X Windows的C/S結(jié)構(gòu)，從而保證Qt程序的的可移植性）。但是QWS并不是一個正式的協(xié)議，從而使得QWS的服務(wù)器和客戶端是緊密耦合的。
因此如果有一個現(xiàn)成的協(xié)議可以利用的話，就會省下Qt開發(fā)者的不少功夫，然后他們最終發(fā)現(xiàn)Wayland（嚴(yán)格說來Wayland也是一個協(xié)議）正是他們所需要的。
在過去的幾個月里Qt的幾名開發(fā)者都在研究Wayland，然后他創(chuàng)建了一個新的實(shí)驗(yàn)室項(xiàng)目Qt-Compositor，這個項(xiàng)目的目標(biāo)是作為一個基礎(chǔ)層讓其他人完成他們自己的Wayland compositor。Qt-Compositor抽象了所有Wayland Compositor所需要的通信。
其實(shí)我想很多人關(guān)心的重點(diǎn)其實(shí)就是Qt現(xiàn)在也有一個可以demo下的Wayland支持啦。雖然開發(fā)者們更多提到的是嵌入式系統(tǒng)，大概也就是想讓Lighthouse替代以前的QWS，Wayland在Qt嵌入式的下一步也有著重要的作用。
#p#
Lighthouse在去年10月底的時候決定和Qt的master合并，評論里面不少人其實(shí)在催xcb支持（X的c語言綁定），后面也回復(fù)有xcb現(xiàn)在也正在開發(fā)中。lighthouse看來將成為Qt的移植性/跨平臺的下一步。
基于UIKit的驗(yàn)證概念的新Lighthouse平臺
也許沒有Android移植那樣令人興奮(但也許會比新的INTEGRITY平臺更加振奮人心，至少對于我是這樣的 )，我剛剛將一個新的概念驗(yàn)證性的、基于UIKit的Lighthouse插件實(shí)現(xiàn)提交到qt-lighthouse代碼倉庫中。
這意味著，如果您仔細(xì)地遵照附帶的README文件中的使用說明(在qt-lighthouse代碼倉庫中的src/plugins/platforms/uikit/中)，您應(yīng)該可以能夠針對iOS模擬器和設(shè)備目標(biāo)構(gòu)建(部分)Qt，并且運(yùn)行一些簡單的Qt Quick應(yīng)用程序。我不得不強(qiáng)調(diào)，這不是一個真正的iOS移植，并且也不會以任何方式被支持。很有可能Qt的很多部分都不工作，甚至這些部分都不能編譯，更不用提那些我甚至都沒有試圖編譯的部分。
即便如此，鑒于QML技術(shù)如此之酷，這個小項(xiàng)目的目標(biāo)就是讓一些簡單的QML應(yīng)用程序可以運(yùn)行在iPhone上， 以檢驗(yàn)Lighthouse在技術(shù)上是否可以完成這個任務(wù)。
編譯和鏈接Qt(然后它可以真正地運(yùn)行)
這個過程絕對是最冗長的部分，而且需要心理足夠強(qiáng)大能夠承受巨大的挫折。我面對過很多問題，例如抱怨一些處理器指令不可用等鏈接錯誤，以及在代碼運(yùn)行時方法返回值和變量突然改變或者歸零等，直到后來我發(fā)現(xiàn)是底層mac平臺gcc的mkspec設(shè)置了桌面相關(guān)的環(huán)境變量， 擾亂了iOS部分。將這部分修正得差不多正確了之后，因?yàn)閕OS基本上是一個POSIX平臺，所以大部分編譯和鏈接“能直接工作”。
Lighthouse平臺插件
我采用了一個比較容易的路徑，就是Cocoa平臺插件實(shí)例中所做的，例如在UIView中顯示(blip)QImage。當(dāng)然這不是最有效率的方式(因?yàn)樵谶\(yùn)行QML的flickr演示程序的時候就可以很容易地看到這一點(diǎn))，但是和我們的快速概念驗(yàn)證的目的很適合。盡管還有一些挑戰(zhàn)，例如在集成事件循環(huán)時，如果一個iOS應(yīng)用程序沒有盡快調(diào)用UIApplicationMain就會導(dǎo)致它會被系統(tǒng)殺死。
#p#
Wayland究竟是什么？
如果在兩年前，它是一個新的“X Server”，在于改善當(dāng)前X Server的不足，從而取代它?，F(xiàn)在，我們已經(jīng)可以用更標(biāo)準(zhǔn)的語言來定義Wayland了，那就是：A Simple Display Server。
沒錯，Wayland是一個簡單的“顯示服務(wù)器”（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只是一個協(xié)議（Protocol），就像X Window當(dāng)前的協(xié)議——X11一樣，它只定義了如何與內(nèi)核通訊、如何與Client通訊，具體的策略，依然是交給開發(fā)者自己。所以Wayland依然是貫徹“提供機(jī)制，而非策略”的Unix程序。
“什么？Wayland還是Server/Client模式？”可以這么理解，但實(shí)際上與X Window的Server/Client有著本質(zhì)的區(qū)別。
讓我們用一張類似前文所示的圖表來重新演示一下，在Wayland的框架下，窗口事件的響應(yīng)是如何進(jìn)行的。
在Wayland的架構(gòu)圖中，最顯著的一些特點(diǎn)是：
它復(fù)用了所有Linux內(nèi)核的圖形、輸入輸出技術(shù)：KMS、evdev，因此已支持的驅(qū)動可以直接拿來用；
Wayland沒有傳統(tǒng)的Server/Client的模式，取而代之的是：Compositor/Client，這不僅僅是換一個名稱而已，后面會講到具體區(qū)別；
還記得前文中“點(diǎn)擊Firefox的刷新按鈕”這個應(yīng)用場景吧？在Wayland里，所有的流程是這樣的：
內(nèi)核收到了鼠標(biāo)發(fā)出的信息，經(jīng)過處理后轉(zhuǎn)發(fā)到了Wayland Compositor，就像之前發(fā)往X Server一樣。
Compositor收到消息后，立馬能知道哪個窗口該收到這個消息，因?yàn)樗褪强偪刂浦行模莆沾翱诘膶蛹夑P(guān)系、動畫效果，因此它知道該坐標(biāo)產(chǎn)生的鼠標(biāo)點(diǎn)擊信息應(yīng)該發(fā)送給誰，就這樣，Compositor將鼠標(biāo)的點(diǎn)擊信息發(fā)送給了Firefox。
Firefox收到了消息，這時如果是在X Window下的話，F(xiàn)irefox會向X Server請求繪制按鈕被按下的效果。然而在Wayland里，F(xiàn)irefox可以自行進(jìn)行繪制而不需要再請求Compositor的許可！這就是傳說 中的：直接渲染機(jī)制（Direct Render）！Wayland不管Client的繪制工作，整個過程變得十分簡單而且高效！當(dāng)Firefox自行完成了按鈕狀態(tài)的繪制后，它只需要通知 Compositor，某塊區(qū)域已經(jīng)被更新了。
Compositor收到Firefox發(fā)來的信息的，再重新合成那塊更新的那塊區(qū)域，將最終桌面效果呈現(xiàn)給用戶。這個過程主要是跟內(nèi)核、顯卡驅(qū)動打交道了。
整個流程是不是很自然、很簡單？
所以結(jié)論出來了：
Wayland的“直接渲染架構(gòu)”徹底結(jié)束了傳統(tǒng)X Window在渲染圖形時需要不停的向Server請求、確認(rèn)再繪制這個繁瑣的過程，理論上響應(yīng)速度有了“爆發(fā)式”增長；
Wayland從根本上消除了“Server+Compositor”的重復(fù)勞動，僅有且只需要有一個“Compositor”合成器而已。
Compostior，就是Wayland上的“X Server”，但是它更純粹，它不像X Server一樣，像個大家長，什么都要管。Compositor只做該做的事情，把上面的過程簡化成任務(wù)便是：
基于Wayland協(xié)議，處理evdev的信息；
通知Client（即應(yīng)用程序）對相關(guān)事件做出反應(yīng)（至于應(yīng)用程序想怎么反應(yīng)，Compositor不需要過問）；
收到Client的狀態(tài)更新，重新合成圖形或管理新的圖形布局。
你意識到了，Wayland Compositor的角色，就像是“X Server”＋“Window Manager”，但它只做份內(nèi)的事情而已。我想你已經(jīng)可以想像Wayland構(gòu)架是如何簡單而且高效了，它一舉解決了“X Window”發(fā)展這么多年來積累的、通過“擴(kuò)展”去解決的那些問題。
看似很美好，那么Wayland現(xiàn)在的可用性如何？大家都知道，GTK+、Qt，現(xiàn)在都是基于X的，它們能順利地移植至基于Wayland嗎？當(dāng)然可以！
逐漸成熟的Wayland周邊應(yīng)用
還記得前面那篇文章中，我說過的這句話吧：“盡管在Linux平臺下，Cairo、Pango的發(fā)揮依然是基于X Window的，但X Window充其量僅僅是一個“backend”而已，并不是少它不行。同理，跨平臺的GTK+、Ｑt也只是視X為其中所支持的后端之一，假如哪天X真的 不在了，更換一個新后端，當(dāng)前的GNOME、KDE也能完整的跑起來。”
你已經(jīng)想到了，GTK＋、Qt，只需要簡單的處理一下后端，便可以跑在Wayland上了。比如：
在當(dāng)前的GTK+3.0開發(fā)分支中，有一個開發(fā)分支是“rendering-cleanup”。“清理渲染”？這是做什么的？聯(lián)想一下那個連Client“怎么渲染”都要管的X Server吧。
對了！GTK+3.0已經(jīng)徹底移除了所有圖形渲染、繪圖方面跟X相關(guān)的部分了，現(xiàn)在它是一個100％基于Cairo繪制的圖形工具庫了（之前GTK+2.x時在2.8開始逐漸轉(zhuǎn)向用Cairo繪制，但一直不徹底）。
這意味著兩點(diǎn)：
GTK+的一直以來評價不怎么樣的跨平臺性，在3.0將有顯著的突破；
GTK+的Wayland后端，已經(jīng)在路上了！
見GTK+跑在Wayland上
當(dāng)然，Qt也有了，限于篇福，這里就不介紹了。
另外一個已經(jīng)在主開發(fā)分支便支持Wayland的東西便是：Clutter。這是一個基于OpenGL的動畫框架，我以前介紹過很多次的GNOME Shell、Moblin， 都是基于Clutter的。在Clutter當(dāng)前1.5.x的開發(fā)分支，Wayland作為其中一個“backend”，已經(jīng)得到了 “experimental”的支持。所以說，GNOME 3.0、MeeGo Netbook很可能會成為第一個應(yīng)用Wayland的桌面環(huán)境。
那么，看來Wayland真的觸手可及了啰？可以這么說，但是還差一點(diǎn)。
Wayland技術(shù)實(shí)現(xiàn)及工作重點(diǎn)
Wayland的核心協(xié)議已經(jīng)實(shí)現(xiàn)的差不多了，它充分利用了Linux內(nèi)核的KMS、GEM、DRM等技術(shù)，另外，它默認(rèn)是支持3D加速的，也就是通過OpenGL ES進(jìn)行圖形的合成——光是這一點(diǎn)，X Window又要淚奔了。
使用OpenGL ES這個子集而非OpenGL，這意味著什么？想想有多少項(xiàng)目是用OpenGL ES的：Android、iOS、WebOS、WebGL……幾乎所有主流的的移動操作系統(tǒng)、瀏覽器3D的實(shí)現(xiàn)，都選用了精簡、高效的OpenGL ES。
我不知道當(dāng)前Android的Display Server、Input/Output是如何實(shí)現(xiàn)的，總之跟iOS相比，在觸控的響應(yīng)上是有差距的。未來，對OpenGL ES有著良好支持的Wayland，不知道會不會給這些基于Linux內(nèi)核的移動操作系統(tǒng)發(fā)力呢？我想是非常有可能的！
這時問題就來了，因?yàn)閃ayland所使用的，都是當(dāng)前Linux下最新潮的圖形技術(shù)。所以理所當(dāng)然的，在驅(qū)動這一層面會有一些廠商跟不上。
拿nVIDIA開刷吧，KMS技術(shù)都出來一年多了，Intel的全部顯卡和AMD部分顯卡已經(jīng)獲得支持了，可nVIDIA壓根就沒有興趣搞這個，以 致于開源社區(qū)利用反向工程，通過“Nouveau”項(xiàng)目讓nVIDIA支持了KMS，當(dāng)然比較遺憾的是，性能跟官方閉源的驅(qū)動是差了相當(dāng)?shù)木嚯x。
所以說，基于Wayland的Linux桌面/移動要真正得到應(yīng)用，驅(qū)動這一關(guān)是一定要解決的。不過正所謂潮流不可檔，nVIDIA遲早會支持這項(xiàng)技術(shù)的。
等到驅(qū)動完全不成問題了，Wayland還需要一個全功能的“Compositor”，這個角色，就由Clutter/Mutter、 Compiz、KWin等當(dāng)前主流的窗口管理器來扮演的，相信只要通過簡單的修改，這些合成窗口管理器很快地就能轉(zhuǎn)變成一個全能的“Wayland Compositor”！
把玩Wayland及展望未來
講了這么多技術(shù)、歷史和業(yè)界，大家肯定枯燥了，究竟現(xiàn)在有沒有可以跑的“Wayland Compositor”可以玩玩呢？當(dāng)然！
現(xiàn)在，只要你從官方取得源碼，然后根據(jù)教程進(jìn) 行編譯，就能跑起一個簡單實(shí)現(xiàn)的“Wayland Compositor”。由于Wayland協(xié)議的靈活性，Wayland Compositor也可以擁有自己的后端：比如直接在DRM上跑Wayland（不需要X），或者在X Window上跑起一個Wayland Compositor（相當(dāng)于在X Window上用Xephyr再跑一個X Window）。
當(dāng)前我在Ubuntu 10.10的圖形環(huán)境下，就跑起了默認(rèn)的這個簡易的Wayland Compositor，幾點(diǎn)說明：
支持透明、陰影和簡單的窗口管理；
所有的圖形繪制，都是通過Cairo-gl（Cairo的OpenGL后端）進(jìn)行；
這是又一個例子，我編譯了Clutter的Wayland后端，成功地跑起了一個Clutter的Demo：即同中Ubuntu Tweak的3D Logo。
除了這個Wayland Compositor本身是跑在X Window之上，其本身合成效果、處理窗口布局等等，都完全沒有用到X，而且整個代碼非常簡潔。未來的Linux圖形，就會像是這樣一個結(jié)構(gòu)簡單又高效的樣子。
相信看完我這些介紹，大家對Wayland是個什么角色，已經(jīng)比較清楚了吧？
簡單的說，它就是一個去除X Window中不必要的設(shè)計(jì)、充分利用現(xiàn)代Linux內(nèi)核圖形技術(shù)的一個顯示機(jī)制，它的出現(xiàn)是自然而然的，它的使命不是為了消滅X Window，而是將Linux的圖形技術(shù)發(fā)揮至更高的一個境界。傳統(tǒng)的X Window（即經(jīng)典X應(yīng)用、Gtk 1.x/2.x等舊應(yīng)用），也會在相當(dāng)長一段時間內(nèi)得到繼續(xù)支持，通過Wayland Client的形式跑在Wayland Compositor上，直到最終升級、取代或被淘汰。
來源：
http://labs.qt.nokia.com/2011/03/18/multi-process-lighthouse/
關(guān)于wayland的介紹，我就扔兩篇tualatriX的blog了做參考了：
http://imtx.me/archives/1573.html
http://imtx.me/archives/1574.html
【編輯推薦】
