Wayland

Wayland只是一個協議（Protocol），就像X Window當前的協議——X11一樣，它只定義瞭如何與內核通訊、如何與Client通訊，具體的策略，依然是交給開發者自己。所以Wayland依然 是貫徹“提供機制，而非策略”的Unix程序。 ^[1] 

（概述圖片來源： ^[2]  ）

在Linux平台 ^[3]  下，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+的一直以來評價不怎麼樣的跨平台性，在3.0將有顯著的突破； GTK+的Wayland後端，已經在路上了。 見GTK+跑在Wayland上，截圖引自：Kristian Shows Off GTK+ 3.0 On Wayland

另外一個已經在主開發分支便支持Wayland的東西便是：Clutter。這是一個基於OpenGL的動畫框架，GNOME Shell、Moblin， 都是基於Clutter的。在Clutter當前1.5.x的開發分支，Wayland作為其中一個“backend”，已經得到了 “experimental”的支持。

2023年5月，deepin V23 Beta版的發佈，宣佈 DDE Wayland ^[8]  已經實現了對wayland顯示協議的支持。

Wayland複用了所有Linux內核的圖形、輸入輸出技術：KMS、evdev，因此已支持的驅動可以直接拿來用。 ^[4] 

Wayland沒有傳統的Server/Client的模式，取而代之的是：Compositor/Client，這不僅僅是換一個名稱而已，後面會講到具體區別。 ^[4] 

內核收到了鼠標發出的信息，經過處理後轉發到了Wayland Compositor，就像之前發往X Server一樣。

Compositor收到消息後，立馬能知道哪個窗口該收到這個消息，因為它就是總控制中心，它掌握窗口的層級關係、動畫效果，因此它知道該座標產生的鼠標點擊信息應該發送給誰，就這樣，Compositor將鼠標的點擊信息發送給了Firefox。

Firefox收到了消息，這時如果是在X Window下的話，Firefox會向X Server請求繪製按鈕被按下的效果。然而在Wayland裏，Firefox可以自行進行繪製而不需要再請求Compositor的許可。這就是傳説中的：直接渲染機制（Direct Render）。Wayland不管Client的繪製工作，整個過程變得十分簡單而且高效。當Firefox自行完成了按鈕狀態的繪製後，它只需要通知Compositor，某塊區域已經被更新了。

Compositor收到Firefox發來的信息後，再重新合成那塊更新的區域，將最終桌面效果呈現給用户。這個過程主要是跟內核、顯卡驅動打交道了。 ^[4] 

Wayland的核心協議已經實現的差不多了，它充分利用了Linux內核的KMS、GEM、DRM等技術，另外，它默認是支持3D加速的，也就是通過OpenGL ES進行圖形的合成——光是這一點，X Window又要淚奔了。

使用OpenGL ES這個子集而非OpenGL，有多少項目是用OpenGL ES的：Android、iOS、WebOS、WebGL，幾乎所有主流的的移動操作系統、瀏覽器3D的實現，都選用了精簡、高效的OpenGL ES。

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”。 ^[5] 

從官方取得源碼，然後根據教程進 行編譯，就能跑起一個簡單實現的“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 和 Xwindow 的區別(1張)

例如，編譯了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上，直到最終升級、取代或被淘汰。 ^[6] 

（Wayland 和 Xwindow 的區別相冊部分圖片來源： ^[7]  ）