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程序。

（概述图片来源：）

在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+的一直以来评价不怎么样的跨平台性，在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 已经实现了对wayland显示协议的支持。

Wayland复用了所有Linux内核的图形、输入输出技术：KMS、evdev，因此已支持的驱动可以直接拿来用。

Wayland没有传统的Server/Client的模式，取而代之的是：Compositor/Client，这不仅仅是换一个名称而已，后面会讲到具体区别。

内核收到了鼠标发出的信息，经过处理后转发到了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的核心协议已经实现的差不多了，它充分利用了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”。

从官方取得源码，然后根据教程进 行编译，就能跑起一个简单实现的“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 和 Xwindow 的区别相册部分图片来源：）