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嵌入式的下一步也有着重要的作用。
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就會導緻它會被系統殺死。
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上，直到最終更新、取代或被淘汰。
來源：
關于wayland的介紹，我就扔兩篇tualatriX的blog了做參考了：
【編輯推薦】
【責任編輯：立方 TEL：(010)68476606】
點贊 0