特点介绍

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”。

现在新出的英伟达显卡有些已经支持了wayland了。