揭开Wayland的面纱（一）：X Window的前生今世

今天大家可能在"Wow! Ubuntu"或其他地方看到了这篇文章：Ubuntu 决定未来将启用 Wayland X-Server。

Wayland 是什么呢？它是 X Window？还是要取代 X Window？它的优势在哪里？Linux 桌面/移动会因此有什么变化？在本篇中，我将回顾历史，展望未来，通过简易的文字，来先回顾一下 X Window，从而继续解答 Wayland。

注：在下对 X Window 的理解仅限于表面，文章中会有不少技术、历史方面的错误，若有大侠指出，不胜感激！

古老的 X Window 和现代的桌面技术

X Window 在 1984 年由 MIT 研发，它的设计哲学之一是：提供机制，而非策略。举个最简单的例子吧：X Window 提供了生成窗口（Window）的方法，但它没规定窗口要怎么呈现（map）或摆放（place），这个策略是由外部程序—- 窗口管理器（Window Manager）所决定的。另外一个 X Window 的主要特点便是：Server/Client 网络模型。不论是本地、远程的应用程序，都统一通过 Server/Client 模型来运作，比如：让远程的应用程序跑在本地上。

X Window 在推出之后快速演化，在 1987 年时候，其核心协议已经是第 11 版本了，简称：x11。这个版本已经将"提供机制，而非策略"这个哲学贯彻地非常彻底，以致于核心协议基本稳定，不需要特别大的改动。于是乎，你看到了，现在是 2010 年，整整 23 年了，X Window 依然是 X11。

你可能会诧异，23 年了，X Window 的核心都没有特别大的变化，它能适应现代桌面的快速发展吗？这就要再次提到 X Window 的设计优势了，X Window 在核心层之外提供一个扩展层，开发者可以开发相应扩展，来实现自己的扩展协议，比方说：

标准的 Window 都是矩形的，我如何用它来画一个圆形的窗口？X Window 协议并未提供，但是通过"shape"这个扩展，X Window 可以实现不规则的窗体。

所以啊，这 23 年，X Window 除了继续完善核心协议、驱动以外，很大程度上，都是扩展使它保持"与时俱进"，比如说：

• 要多头显示支持，这个是由"Xinerama"扩展实现的；

• 要有多媒体视频回放的支持，这个是由"X Video"扩展实现的;

• OpenGL 的 3D 支持，则是通过"GL"扩展来实现的；

• Compiz 那样的合成桌面特效是怎么弄的？没错，还需要一个新的扩展，它便是：“Composite”；

• 甚至 Keyboard 的支持，都是通过"X Keyboard Extension"（也就是"XKB"）的！

X Window 的核心，基本上就是在处理 Server/Client、驱动之类的，而外部的那些支持，基本上全是通过"扩展"进行的。这没什么不好，X Window 的结构设计精良，尽管是扩展，但它们没有任何效能上的问题。通过扩展方便地实现了一些对新技术、新事物的支持，而且方便维护，这再好不过了。

所以你看到了尽管 23 年过去了，基于 X Window 的 GNOME、KDE，还能保持与同期 Windows、Mac OS X 竞争甚至某些方面更好，你就不得不佩服这些前辈在最初设计时定下的设计哲学是多么正确了。

虽然扩展的众多没有给 X Window 造成什么问题，也跟 X Window 的设计哲学相符，但是其 Server/Client 的网络构架，却一直倍受质疑，这便是：

X Window 的效率问题

经常听到有人说，X Window 的 Server/Client 结构严重影响效率，导致 Linux 桌面的效应速度一直不如 Windows、Mac OS X。事实是不是这样呢？让我们还是透过原理来说话吧。

这张，便是当前 X Window 系统的架构图，稍微解释一下：

• X Client：图形应用程序，如 Firefox、Pidgin 等；

• X Server：你看不见的控制中心；

• Compositor：合成桌面系统，如 Compiz；

• Kernel/KMS/evdev：这便是 Linux Kernel，后面会提到 KMS 技术了，其中还有一项 evdev，是管理输入设备的。

通过这些箭头，你已经可以明白一些 X Window 的工作机制了，不过还从一个应用场景来解释一下，想像一下，当你点击了 Firefox（X Client）的"刷新"按钮，将会发生以下事情：

1. 你用鼠标点击了 Firefox 的"刷新"按钮，这时内核收到了鼠标发来的事件，并将其通过 evdev 输入驱动发送至了 X Server。这时内核实际上做了很多事情，包括将不同品牌的鼠标发出的不同信号转换成了标准的"evdev"输入信息。
2. 这时 X Server 可以判断哪个 Window 该收到这个消息，并将某座标按下按钮的消息发往 X Client—-Firefox。但事实上 X Server 并不知道它得到的窗口信息是不是正确！为什么呢？因为当前的 Linux 桌面早已经不是 10 年前的那样了，现在是"Composite"即合成桌面的时代，合成桌面的一个特点便是：Compositor（如 Compiz）管理窗口的一切，X Server 只能知道屏幕的某个点收到了鼠标消息，却不知道这个点下面到底有没有窗口—-谁知道 Compiz 是不是正在搞一个漂亮的、缓慢的动画，把窗口收缩起来了呢？
3. 假设应用场景没这么复杂，Firefox 顺利地收到了消息，这时 Firefox 要决定该如何做：按钮要有按下的效果。于是 Firefox 再发送请求给 X Server，说：“麻烦画一下按钮按下的效果。”
4. 当 X Server 收到消息后，它就准备开始做具体的绘图工作了：首先它告诉显卡驱动，要画怎么样一个效果，然后它也计算了被改变的那块区域，同时告诉 Compiz 那块区域需要重新合成一下。
5. Compiz 收到消息后，它将从缓冲里取得显卡渲染出的图形并重新合成至整个屏幕—-当然，Compiz 的"合成"动作，也属于"渲染（render）"，也是需要请求 X Server，我要画这块，然后 X Server 回复：你可以画了。
6. 整个过程可能已经明了了，请求和渲染的动作，从 X Client->X Server，再从 X Server->Compositor，而且是双向的，确实是比较耗时的，但是，事实还不是如此。介于 X Window 已有的机制，尽管 Compiz 已经掌管了全部最终桌面呈现的效果，但 X Server 在收到 Compiz 的"渲染"请求时，还会做一些"本职工作"，如：窗口的重叠判断、被覆盖窗口的剪载计算等等（不然它怎么知道鼠标按下的坐标下，是 Firefox 的窗口呢）—-这些都是无意义的重复工作，而且 Compiz 不会理会这些，Compiz 依然会在自己的全屏幕"画布"上，画着自己的动画效果……

从这个过程，基本可以得出结论：

1. X Client <-> X Server <-> Compositor，这三者请求渲染的过程，不是很高效；
2. X Server，Compositor，这两者做了很多不必要的重复工作和正文切换。

当然，这里我没有直接说明这种模式有没有给 X Window 造成效率问题，因为我们还少一个对照组。再看对照组之前，再来看看 X Server 的另一个趋势：

从"什么都做"到"做得越来越少"的 X Window

X Window 刚出现那会，主要提供一个在操作系统内核上的抽象层，来实现一个图形环境。所谓图形环境，最主要的便是：图形＋文字。当时的 X Window 便提供"绘图"和"渲染文字"的机制。图形桌面上的图案和文字，都通过 X Window 合成并绘制出来。

一个典型的例子，如果你要用 X 来画点，就要在你的程序中通过"XDrawPoint"来进行，X Server 收到消息后，便会画出相应的点。

现在，稍微接触过图形开发的人都知道了，在 X Window 下，一般都通过 GTK+和 Qt 来进行了。更深一层的是，通过 Cairo（Qt 不是）来绘制图形。Cairo 是什么？它是一个绘图＋渲染引擎，著名的浏览器 Firefox，便是使用 Cairo 来渲染网页和文字的。

Cairo 是一个全能的、跨平台的矢量绘图库，它不是简单的包装一下各个平台的绘图库而已，尽管它最初是基于 X Window 开发出来的绘图库。现在 Cairo 支持各种不同的后端，来向其输出图形，比如 X、Windows 的 GDI、Mac OS X 的 Quartz，还有各种文件格式：PNG、PDF，当然还有 SVG。可以说，Cairo 是一个很彻底的、全能的绘图库，现在无论绘制什么图形，都不会考虑到用 XLib 了。

在 Cairo 之上，还有文字排版库：Pango，同样很明显的，处理文字排版，都不会用 XFont 之类的东西了，而是直接用 Pango 画。当然 Pango 也是跨平台的。

尽管在 Linux 平台下，Cairo、Pango 的发挥依然是基于 X Window 的，但 X Window 充其量仅仅是一个"backend"而已，并不是少它不行。同理，跨平台的 GTK+、Ｑ t 也只是视 X 为其中所支持的后端之一，假如哪天 X 真的不在了，更换一个新后端，当前的 GNOME、KDE 也能完整的跑起来。

再提另外一个比较典型的关于"X 曾经做的，但现已不做"的例子，便是"模式设置（mode- setting）"，说通俗点，就是"分辨率的设置"，但后面会说明不仅仅如此。

大家都知道，Linux 只是一个内核，它只有控制台，通过 Shell 来进行交互，而控制台默认是 80x24（单位：字符）的，要进入分辨率 1024x768 或更高的图形模式，就需要 X 进行一次"模式设置"，设置正确的分辨率等等。

尽管后来 Linux 也支持了各种用户层（user- space）的模式设置，让终端也支持标准的分辨率，但是 X 的模式设置与此是不相干的，所以一两年前，在 Linux 的启动过程中，从终端进入图形界面时，屏幕会"闪"一下，这时便在进行"模式设置" —-这里就一定要用"模式设置"这个术语了，因为即使终端是 1024 的，进入 X 图形也是 1024 的，模式的变更还是要进行。

后来呢，嗯，2009 年初期，KMS（内核模式设置）终于出现了！！！很少关心桌面图形的 Linux 内核，在当时引入了"内核级"的模式设置，也就是说，在内核载入完毕、显示驱动初始化后很短的时间内，即设置好标准的分辨率和色深，通过在 X 层做相应的更改，从此 X 的初始化就可以省去"模式设置"这一过程了！也就是从 Fedora 10 开始，Linux 的启动非常平滑、漂亮，没有任何闪烁了。现在的 Ubuntu 10.10 也一样，KMS 的应用已经相当成熟。

X 从此又少了一样图形任务……“X 泪奔～你们都不要我了。”

可以说，这 20 多年来，X 从"什么都做"已经到了"做的越来越少"。绝大多数的开发者开发图形应用程序，已经可以完全无视 X 的存在了，X 现在更像是一个中间人的角色。那么，X 这个中间人会不会有一天，完全被其他事物所取代呢？

没错！它便是下篇要介绍的：Wayland！！！