慧中也要秀外 – X Window 体系初探

Linux 系统在服务器领域应用取得了巨大的成就，同时，针对桌面级的 GUI 应用需求，如排版、制图、多媒体等，Linux 也有独有的技术体系来应对。其中，核心的技术体系就是 X Window System。

X Window System 的缘起

X 起源于 MIT 的 “雅典娜项目(Project Athena)”。Athena 项目是由 MIT、DEC、IBM 联合发起一个项目，目的在于构建一个为教育服务的校园范围内的分布式计算环境。

在 70 年代末 80 年代初的时候，计算机在 MIT 的科研工作中已广泛使用，但普通本科生除了少数特定的专业（计算机科学和工程），很少有机会使用计算机。为了使计算机不再局限于小范围使用，而是让更多其他专业的学生也能使用到计算机的强大功能，并从中获益，MIT 决定基于校园网络，构建一个基于 Unix 的分布式计算系统，使得学生通过终端的登录，就能使用中心服务提供的统一的文件和程序资源。

为了支持这一项目，DEC 和 IBM 相继参与进来，提供了资金、设备、人员的支持。DEC 和 IBM 两家商业公司提供助力的同时，也为项目提出了更高的要求和更大的挑战。两个厂商各自生产的计算机互不兼容，Athena 项目希望在软件层面上屏蔽不同供应商硬件方面的差异，使得 Athena 项目的软件都有一致的用户接口。这样也达到 MIT 在 Athena 项目结束时不依赖任何一个单独的供应商的目的。在这样的背景下，Athena 项目不断演化发展，X window System 也在其中应运而生。

Athena 项目自 1983 年开始，至 1991 年研发结束。直到 2020 年，Athena 仍然在 MIT 使用。它并非一个纯科研的项目，而是源自于一个校园工程应用需求，却成就了诸多前沿创新，这些创新对后续计算机技术发展产生深远影响。Athena 项目直接创立了 X Window System、Kerberos 和 Zephyr Notificaition，并且影响了 thin (client) computing、LDAP、活动目录(Active Directory) 和即时通讯等技术的研发，在桌面和分布式计算的历史上有重要地位。

X Window System 是 Athena 项目的核心成果，Athena 项目的特点也决定了 X Window System 的基本特征：

一种用于位图显示器的窗口系统
一种基于网络的显示系统
一种与硬件平台无关的显示系统（独立于硬件、独立于厂商）
与 Unix 类系统天然的契合度

经过多年发展，X Window System 也逐步从高校转化到产业界。历经 MIT 及各厂商、大学等的无数版本迭代后，1987 年，X 的版本来到了 X11，这是一个里程碑式的版本，并取得了明显成功，几乎后来所有的分支都是基于 X11 开发的。因此，X Window 有时也被 X11。

在发展过程中，X 开发的主导者也经历了一系列的变化，包括 MIT、MIT X Consortium、X Consortium,Inc、The Open Group、X.Org、XFree86、X.Org Foundation 等机构，期间也产生了授权纠纷等各种各样的问题。

X Window System 概念设计

X 系统在设计之初就希望窗口界面与硬件不要有强烈的相关性，这种松耦合可以使 X 系统适用于更广泛的硬件平台，这种诉求也导致 X 系统在整体软件层级结构中所处的层级较高，X 是以一个应用程序的概念来开发的，而非作为底层操作系统来研发。

(X 系统作为应用程序特性与 Windows 3.2 图形界面的定位有相似之处。X 系统可以通过命令行直接启动，Windows 3.2 图形界面也可以通过 DOS 命令行启动)

同时，X 系统期望充分利用分布式计算环境，X Window System 采用分层的结构，设计为一个网络化的图形显示应用系统。整体架构上，分为 “服务端组件 — X Server” 和 “客户端组件 — X Client” 两大部分，两者之间通过 X11 协议进行通讯。

X Server，顾名思义，是整个体系的服务端。与传统的网络中的服务器相比，其共同点是都是对外提供某种服务，不同的是，X Server 所提供的服务有些特殊 — 它的核心任务就是提供”显示服务”，说白了，就是给用户提供显示画图的功能。
为了达到显示服务的目标，X Server 必须对显示服务的所需的关键要素、关键任务进行管理，包括：
- 对显示服务器上的相关硬件进行管理：输入设备如键盘、鼠标、手写板；输出设备如显示器(monitor)等；
- 管理显示用的字体；
- 完成屏幕绘制的任务；
X Client，是整个体系的客户端。它的主要任务就是告诉 X 服务端，该在 X 服务器上画些啥、该显示什么内容。因此，X Client 的目的就在于产生“绘图数据”，并将这些数据回传给 X Server，进而让 X Server 基于这些数据进行画图和显示。
- X Client 的任务非常明确，就是产生“绘图数据”，为此，X Server 虽然管理服务器上相关硬件，但一旦硬件上产生了可能影响绘图数据的动作（或事件），X Server 都不自己处理，决不干涉绘图数据的生成，而是将事件告知 X Client，由 X Client 根据事件情况，重新生成相关的绘图数据，再回传给 X Server 进行显示。从用户输入到屏幕输出，经历了一个 输入设备 --> X Server --> X Client --> X Server --> 输出设备 的过程；
- 这些绘图数据都是基于 application 产生，因此 X Client 也被称为 X Application。

由此可见，X Window 的 Server/Client 体系与传统网络中的 Server/Client 体系的不同，其核心区别点就在与提供什么样的服务。当数据内容作为服务的核心时，就是传统的 Server/Client，Server 端拥有数据，Client 使用数据时，向 Server 端索取数据。而 X Windows 体系是将绘图显示服务作为服务的核心，依此目标，Server 端完成绘图显示任务，Client 端为绘图显示提供显示数据支撑。

也就是说，在 X Window 体系中，哪里提供显示服务，哪里就是 Server。这也就意味着，X Server 往往是运行于与用户直接交互的计算机上。

比如在 Athena 项目中，每个学生使用的终端机器上运行的是用于显示的 X Server 软件，而存放教学资源的数据中心的运行的则是 X Client。

X 系统是一种基于网络的显示系统，其服务器和客户端也可以运行于同一台机器上。使用 Linux 桌面发行版这种情况比较常见。

典型的 X Server 设计

无疑，服务端 X Server 软件是整个 X Window System 最核心的组件，是 X Window System 提供显示服务的关键，因此，X Server 也被称为 display server。

为了完成 display server 的显示服务功能，X Server 必须完成好两项基本任务：

控制、协调好输入设备、输出设备；
通过网络协议（X11）与 X Client 进行数据交换；

最初设计软件时，X Server 功能逻辑定位较高，作为一个应用软件来设计，不直接面对底层硬件，因此，X Server 控制一般的输入输出设备，以及进行网络的底层通信时必须借助操作系统内核提供的功能来驱动完成。另外，X Server 程序和所有的 X Client 程序，都是以独立的进程形式存在，在 Unix/Linux 系统中，X Server 进程和 X Client 进程间并不知道彼此的任何信息，它们之间进行通信，必须完全依靠操作系统内核提供的 inter-process communication (IPC) 机制来协调。

以当前主流的 display server — X.Org Server 为例。X.Org Server 利用内核中的 evdev，将各种输入设备的输入转化为 event，并进行处理；利用 DRM/KMS 进行图形设备的驱动；利用 network stack 进行网络层数据传输驱动。与此同时，X.Org Server 与各种 X Client 之间采用 Sockets 作为 IPC 方法，为 TCP/IP domain 和只用于本机的 UNIX domain 分别提供了 API 接口。如果 X Server 进程和 X Client 进程处于同一台计算机，则它们之间就可采用效率更高的 UNIX domain 方式进行 IPC 通讯。

X Server 内部设计

同样以 X.Org Server 为例，在 X.Org Server 的内部架构设计中，将于设备无关的部分与设备有关的部分进行拆分。

设备无关的部分称为 Device Independent X (DIX)，这部分执行与 X Client 进行交互，并完成软件渲染任务（rendering）。DIX 完成与 X Client 交互功能，因此需要实现对 X 协议核心内容的支持，包括 code tables、glyph rasterization and caching、XLFDs、支持绘图源语（graphics primitives）的渲染 API 等。
设备依赖的部分称为 Device Dependent X (DDX)，这部分主要处理与硬件相关底层交互，主要是驱动程序。包括显卡、鼠标和键盘。每种驱动都设计为一个独立的 loadable module，以一个 .so 文件的形式存在。在操作系统中，存放在 /usr/lib/xorg/modules/ 文件夹中。

典型的 X Client 设计

特殊的 X Client – Window Manager

在 X Window 体系的交互关系中，X Server 作为提供服务的一端，要应对处理来自许多不同的 X Client 的绘图需求。而每个 X Client 都单独与对应的 X Server 进行交互，每个 X Client 并不了解是否有其他 X Client 的存在，以及其相关的动作。可以说，X Ciient 与 X Client 之间是背靠背的。由此，会直接导致的一个问题就是对 X Server 对多个 X Client 绘图数据管理的问题。比如，不同的 X Client 给同一个 X Server 反馈了同样的绘图位置信息，进而造成不同 X Client 在 X Server 显示中的重叠或覆盖。

针对这种情况，X Server 必须对所有的 X Client 进行管理。X Server 给出的解决方案是，使用“一个特殊的 X Client”，来管理所有的 X Client。这个特殊的 X Client，称为 Windows Manager（即 WM，窗口管理器）。

窗口管理器 (Window Manager) 的任务，就是在 X Server 中管理所有的 X Client 成员。可将其视为“中控 X Client”，其典型的任务包括：

控制各个窗口的行为
- 改变窗口的大小，窗口的最小化、最大化
- 窗口的移动
- 改变窗口的层叠顺序
控制各个窗口的外观
- 窗口的标题、按钮、边框等

窗口上的标题，按钮，漂亮的边框等装饰元素（window decoration），全都是窗口管理器提供的，而不是程序自己的，这样用窗口管理器就能改变任何窗口的样式了。当点击关闭窗口的那个按钮，其实点击的是窗口管理器放在程序窗口上面的一个小窗口，发现它受到点击后，窗口管理器就会通知那个程序：“喂！有人想关掉你，你自己准备准备，然后退出吧。”

不同的机器在本机显示的窗口，由窗口管理器统一装饰和指挥。比如，窗口管理器决定： xterm 窗口上面都应该有四个按钮，一个在左边，点击它会显示窗口操作菜单，另外三个在右边，分别是最大化，最小化和关闭。窗口都使用 7 pixel 厚的边框，窗口首次出现的时候首先在桌面上找一个空位置，如果找不到，就找一个能够最少的遮盖其它窗口的位置 ……

百花齐放的窗口管理器

Window Manager 在 X Window 体系中窗口管理方面的关键、核心地位，因此也是 X Window 体系发展过程中的焦点之一。经过多年的发展，也产生了的各种各样的 Window Manager。每种 Window Manager 对窗口的管理风格和方法都不尽相同。根据管理窗口的不同角度，可以将 Window Manager 进行不同分类。

按照窗口在屏幕上的摆放(布局)方式不同，可将 Window Manager 分为以下三类：

Stacking (aka Floating) window managers（“堆叠式”（悬浮式）窗口管理器）
堆叠式（或悬浮式）窗口管理器，其管理的不同窗口之间可以相互重叠，就像桌子上随意摆放的白纸一样。
Tiling window managers（“平铺式”（瓦片式）窗口管理器）

tile, 译为地砖；瓦片；Tiling window manager, 将窗口像地砖一样平铺的管理器。

平铺式（或瓦片式）窗口管理器，其管理的窗口不能够重叠，而是像瓦片一样一个挨一个摆放。

与堆叠式管理器相比，平铺式窗口管理器的窗口通过“平铺”的方式直接占满整个显示区域，对显示屏幕的利用率更高。所有窗口都直接呈现在显示屏幕上，不存在有窗口“藏在背后”的情况。这种全屏幕、全窗口的窗口管理特点，对基于终端的操作场景、多 monitor 的分屏显示都非常合适。
Dynamic window managers（动态式窗口管理器）

动态窗口管理器，则将上述两种窗口管理器结合起来，可以在 tiling 和 floating 之间动态切换窗口的放置方式。

根据所管理的窗口的绘制更新方式不同，又分为以下类型：

Compositing window managers（组合式窗口管理器）
组合式窗口管理器，可以让其管理的所有窗口分别进行独立的创建和绘制，并且，可以将这些独立绘制的窗口整合到一起并在各种 2D 或 3D 的环境中显示。

这种方式的最大优势就是，可以在一个环境中展示各种不同的窗口样貌和风格，并呈现高级的 2D 或 3D 可视化效果。

(组合式窗口管理器，真正提供了一个“多样式”的窗口展示环境。)

当前 Linux 的主流窗口管理器，基本都为组合式窗口管理器。如 GNOME 3 中的 Mutter；KDE 中的 KWin，在4.0 版本后，引入组合功能；XFce 中的 Xfwm，在 4.2 版本后，也整合了自己的组合管理器。
Non-compositing window managers
与组合式窗口管理器正好相反，这种 window manager 下，所有窗口都是统一创建和绘制。这也是 window manager 传统的功能。

各类窗口管理器各具特色，每一类窗口管理器都有多种实现。Wikipedia 上有特定的专题做了详尽的比较。

窗口管理器与桌面环境 (Desktop Environment)

Gnome 与 KDE 是 Linux 最常见的两种发行环境，有时他们也会被称为”窗口管理器”。这是一种典型的错误理解。

Gnome 和 KDE 称为“桌面环境 (Desktop Environment)”，本质上，”桌面环境”是一种高度集成化的程序和函数库的集合。它们中不仅包含窗口管理器，同时，还有很多其他实用的 X Client 应用程序，比如配置程序、工具条、编辑器、绘图工具等等。桌面环境的设计目的是要提供一套风格一致的用户接口，来满足用户的需要。桌面环境的概念，不仅针对 Unix-like 的系统，对 Windows 系统也适用。

随着 X Window 系统的发展，也出现了多种桌面环境。每一种桌面环境都拥有自己的窗口管理器。例如，Gnome 可以和很多窗口管理器合作，在历史上，Gnome 使用过的窗口管理器包括 englightenment, sawmill, sawfish, metacity、Mutter。KDE 的窗口管理器是 KWin。

特殊的 X Client – Display Manager

窗口管理器 (Window Manager) 与显示管理器 (Display Manager)

显示管理器 (Display Manager)，也称为“登录管理器 (login manager)”，顾名思义，它本质上就是一种提供”登录功能”的特定软件。Display Manager 提供了一个图形化的登录环境，通过它，可以启动 X Server。这个 X Server，既可以是本地计算机上运行的 X Server，也可以是远程计算机上运行的 X Server。可以说，Display Manager 是图形化方式启动 X Server 的前置条件。

X Window 系统使用 XDM (X Display Manager) 作为其标准的 Display Manager。经过多年的发展，和 Window Manager 和 Desktop Environment 一样，Display Manager 也出现了许多不同的实现，在基本的显示管理基础上，提供了许多额外的功能。

gogetter

总结，前进

慧中也要秀外 – X Window 体系初探

X Window System 的缘起

X Window System 概念设计