1980年代初，麻省理工学院计算机科学系(以下简称MIT)的Bob Scheifler 着手为新的窗口系统制定规则。他决定取名为X，因为此窗口系统是基于W窗口系统的一个改进，W窗口系统源于V系统。X窗口系统将掀起一场图形领域的革命。当时X确实成为了所有类UNIX窗口系统的标准图形服务器，因为它的特点和理念远远超越了竞争对手。短短几年时间，UNIX社区全部接纳了X窗口系统。
在这篇文章中，我们将一瞥Linux图形栈的发展历程，从最初的X客户端/服务器到现在的Wayland所做的一系列努力。
X变得如此特殊，不得不说，这简直是一个传奇。X是面向网络、基于分布式的第一个图形服务器。在分时系统上，一个X服务器可以同时为多个客户端服务。X的网络协议使本地窗口能够显示在远程机器上。实际上，X就是面向网络的，协议独立于硬件。通过网络协议发送显示请求，运行于某个类UNIX平台的X客户端可以在完全不同硬件平台的类UNIX系统上显示。
窗口外观独立于X服务器。X协议定义了显示设备和窗口原语信息，窗口的具体外观只与控件库、窗口管理器和桌面环境有关。
在Bob Scheifler的主导和MIT的管理下，更多的人开始对此萌发兴趣。为了X将来更好的发展 ，那时的企业翘楚，例如美国的数字电子公司(DEC)，可免费获取到源代码。同时，一批厂商询问MIT，是否有某种措施能够维持源代码的完整性，好让X能够造福于所有对此感兴趣的组织机构。MIT同意了，不久之后，MIT X 协会成立，同时发布了源码，包括DEC对X的改善部分。此次X源码的发布确实是一个值得关注的事件。厂商们意识到，X已经有很高的价值了，需要避免某个公司获得对X的控制，更好的保护大家的心血，而维持X源码的开放是最重要的原则，同时MIT X 协会一直对X源码拥有版权，避免了X被私人商业公司拥有。
1988年，协会招募了一个高级开放者Keith Packard，他将重新实现X服务器的核心。现在，Packard在Linux图形栈领域已经众人皆知了。
尽管X在UNIX和Linux图形栈领域占据统治地位，但由于X的流行，基于X的、产生大量绘制请求的软件和大量的软件最终拖累了X本身。90年代，Linux快速流行起来，对于运行于同一机器上的X Server/client，开始使用X配置文件，同时X开始捆绑在很多Linux发行版上。对于本地显示来说，X基于网络的设计毫无用处，这一曾经大肆吹嘘的优点现在反而成为视频绘制的瓶颈。
这段时间，个人电脑的销售激增，专业图形显卡的复杂特性开始超越X的处理能力，更多高性能的显卡持续不断的开发出来。
转换表映射（以下简称TTM）的出现
2004年左右，一些Linux开发者开始对X缓慢的发展逐渐感到失望。1992年，他们开始转向OpenGL,一种图像渲染API，最初是用来显示2D和3D图形的（源于硅谷图形公司开发的）。经过几年X在显卡上绘制3D图形的尝试，最终没有一个方案可行。
然后在2007年，Thomas Hellstrom, Eric Anholt, 和 Dave Airlie共同开发了一个内存管理模块，他们称做TTM。TTM用于显存和系统内存之间的缓冲拷贝。当时在Linux社区引起了很大反响。它为那些对3D性能有严格要求的图形应用带来了希望。这个方法就是将内存缓冲区作为第一个类对象传递给应用程序使用，同时允许应用程序分配和处理内存缓冲区中的图形信息。TTM可以管理主机上所有应用程序的缓冲区，并且提供GPU和CPU之间的同步，这个过程是通过一个特殊信号fence完成的。当GPU完成对某个缓冲区的显示处理后，通过fence信号将此缓冲区的控制权交给此缓冲区对应的应用程序，此时CPU重新接管缓冲区。
平心而论，应用程序对GPU访问方式的标准化，TTM确实做了一个勇敢的尝试，它是Linux上针对所有显卡驱动的内存管理器，简言之，TTM尝试提供所有图形应用程序可能需要的所有操作。不幸的是，TTM代码量和API过于庞大，而每一个独立的开源驱动仅仅只需要API集合中的一个小子集。大量的API容易使开发者迷惑，他们需要决定选择使用哪个API。最大的抱怨是TTM还有一些性能问题，可能是由于CPU和GPU之间的信号同步机制（fence)导致，或者是缓冲区对象的拷贝效率太低。TTM可能确实要处理很多事情，不过这不能成为它变得缓慢的借口。
2008年，Reenter Keith Packard宣布了一个TTM的替代方案。Keith到目前为止还在Intel工作。得益于Eric开发TTM的经验教训，同时在Eric的帮助下，他们重写了TTM。新的API叫图形执行管理器（以下简称GEM），一般开发者通过API就能大致猜到下一步要做什么，相对于TTM庞大的API，开发者不会迷失于GEM的API中。
相对于TTM，GEM有很多提升，其中一个计较有意义的提升就是API接口的设计很严谨，同时TTM中伤脑筋的fence信号概念也去掉了。Keith和Eric让应用程序接管API之上的内存部分，GEM则专心处理GPU可访问的内存部分，并处理显卡执行的上下文信息。应用与内核空间的交互访是通过ioctl()调用，不存在TTM那种不停的缓冲区拷贝。GEM更像是一个面向流的API，而不是内存管理器。
GEM允许应用程序共享内存缓冲区，GPU处理的内存空间就不需要重新装载。以下是原始的发行说明：
“Gem为Linux操作系统提供简单的机制来管理图形数据和控制执行流程。很多内核子系统实现了这种机制。”
随着GEM在2008年5月的出现，给Linux的图形栈带来了更多的希望。GEM并不处理所有事情。例如，GPU执行的命令由设备对应驱动提供。因为Keith和Eric在Intel工作，GEM对Intel驱动支持的开源代码编写工作理所当然落在了他们身上。同时希望GEM能够支持更多其他的驱动，例如三个最大的显卡制造商。
然而，采用GEM的非intel显卡驱动很慢。一些迹象表明AMD驱动选择了一个“类似GEM和TTM管理器”的方案，预示着AMD并不愿意加入到GEM的阵营，GEM面临单枪匹马的危险。
TTM和GEM尝试在X中整合对GPU的操作以解决Linux图形栈上的3D加速问题。两者都是为了更好的提升不同图形库的显示性能，例如OpenGL(依赖于X), Qt(依赖于X)和GTK+（也是依赖于X)。问题是X处于所有图形库和内核之间，只有内核能够访问设备驱动，然后驱动才能访问到GPU。
X已经老掉牙了。X拥有数百万行代码，很多代码已经很陈旧，那是还没有GPU，没有专业的晶体管处理可编程着色技术或者旋转操作以及顶点翻转，既不知道高密度采样和用插值法减少反锯齿效果的概念，也不清楚如何创建极高精度的颜色空间。此时不同往日，X已经不能满足现在的需求了。
Wayland:一个新的显示管理器
2008年，一个叫Kristian H?gsberg 的软件工程师在波士顿的市郊上开着车，可能是去往工作的路上，亦或是回家，软件工程师正深入的思考着，有时他们会花费大量时间解决复杂的问题，将问题打散并进行重构。当他们工作疲劳休息时，会产生一些灵感，这种灵感往往能够为项目带来更大的突破。当人们在洗澡或者在厨房烹饪时，或者在驾驶途中，这种灵感更易产生。 当H?gsberg驱车于马萨诸塞州Wayland一个很小的村庄时，他的大脑中迸出一个想法并渐渐成型，这个想法用他自己的话说：
“核心思想是所有窗口被重定向，我们可以让所有客户端自己去渲染自己，然后传递一个缓冲句柄给显示服务器，显示服务器中的混合器完成窗口显示工作。其中一个目标就是让X服务器运行于Wayland上，首先支持全屏窗口（例如Xnest)，然后支持父窗口等，直到X被最终淘汰。”
他的想法是写一个全新的显示管理器，管理器可绕过X直接向内核发送3D显示请求。X自己就是显示管理器的一个客户端，正如以上作者所说，新的显示管理器取名为“Wayland”，以此表达对这个小镇的敬意。
这仅仅只是一个想法。很多人每天都会产生大量聪明的想法，但最终都被生活中的杂事所磨灭。 H?gsberg正从事于图形渲染库方面的工作，他大概觉得，如果应用程序都能直接访问GPU，没有X在中间搅局，那一切事情都变得简单了。他着手写代码解决这个问题。根据Intel的员工Keith Packard所说，两周后，H?gsber完成了雏形。
Wayland的一个关键特点是完成渲染工作的API完全不依赖X。为了保持兼容性，X服务器本身就是Wayland的客户端,所有X所做的渲染直接发给Wayland。像X一样，Wayland仅仅定义协议。Wayland的体系结构和X本身的特点，给X客户端的移植带来了很大便利，同时还兼容以前的X客户端程序。
Wayland显示管理器会使用内核中的GEM(图形执行管理器)、evdev(输入事件驱动)和kms(内核模式切换）。Wayland有自己的混合器，这与X形成鲜明的对比，X依赖外部的混合器处理显示相关的内存缓冲。
Wayland也会使用DRI2。Wayland混合器和Wayland客户端都能够访问屏幕显示相关的资源。当客户端更新了这个缓冲，混合器将更新桌面，并重绘屏幕。
Wayland确实解决了很多X无法解决的问题，大家对此项目感到兴奋，一群聪明的人正在实现它，并且Intel和redhat也在支持这个项目。
但是还有一些障碍需要克服。两个最大的障碍就是开发兼容NVIDIA和AMD的开源驱动。第三大显卡厂商Intel已经兼容了Wayland，因为GEM内核模块就是基于Intel驱动开发的。
谁会为Wayland更新AMD和NVIDIA的开源驱动？对开发者来说，Linux下开源显卡驱动的开发很折磨人，因为你没有完整的硬件规范手册，甚至什么资料都没有，只能通过枯燥的逆向工程获取显卡规范信息。
nouveau驱动就是一个很好的例子。当时，NVIDIA开发者放出话来，表示我们没有支持Wayland的计划。所有工作压向Linux社区，有时有一些厂商的支持，有时什么都没有。在nouveau项目中，开发者正通过逆向工程积极的开发NVIDIA驱动。一个叫做Renouveau(nouveau的逆向工程）的执行流程如下：
1. 记录MMIO寄存器的内容；
2. 绘制图形；
3. 记录寄存器中的新值；
然后向Renouveau工程的ftp服务器发送绘制前后内存转储的文本格式差异信息，这些文件是为以后的显卡分析做准备。
相对于NVIDIA，AMD这方面的工作进展更顺利。过去几年中，新成立的团队正在开发AMD的开源驱动，根据开发团队周期性发布的规范说明，各地开发者皆可持续驱动的研发。驱动名称是fglx(FireGL and Radeon for X）,Linux社区每月都可以从AMD获得显卡的最新信息。
Wayland在Linux图形栈方面很有优势。最近，Ubuntu计划在Wayland上使用他们自己的窗口管理器Unity。为了确保硬件驱动能在新的图形架构上发挥最大性能，Intel强力支持协助开发GEM，雇佣了Wayland的开发者们。
除此以外，图形领域正在两极分化。AMD和NVIDIA正忙于争夺市场份额的激烈竞争，开源社区的开发需求还排不上他们的议程。
Linux社区是基于协作来完成开发。多年以来，通过合作和开放，Linux急速发展，而Linux图形栈似乎不为所动。图形硬件厂商可选择是否向开源社区贡献力量，但很多厂商持不情愿开源的态度。那些拥有高性能图形显卡的厂商难道不想让他们的用户拥有最好的用户体验？将产品信息隐藏起来，这些难道不会伤及他们的产品线？可以毫无疑问的说-他们违反了开源精神。
在这篇文章中，我们将一瞥Linux图形栈的发展历程，从最初的X客户端/服务器到现在的Wayland所做的一系列努力。
X变得如此特殊，不得不说，这简直是一个传奇。X是面向网络、基于分布式的第一个图形服务器。在分时系统上，一个X服务器可以同时为多个客户端服务。X的网络协议使本地窗口能够显示在远程机器上。实际上，X就是面向网络的，协议独立于硬件。通过网络协议发送显示请求，运行于某个类UNIX平台的X客户端可以在完全不同硬件平台的类UNIX系统上显示。
窗口外观独立于X服务器。X协议定义了显示设备和窗口原语信息，窗口的具体外观只与控件库、窗口管理器和桌面环境有关。
在Bob Scheifler的主导和MIT的管理下，更多的人开始对此萌发兴趣。为了X将来更好的发展 ，那时的企业翘楚，例如美国的数字电子公司(DEC)，可免费获取到源代码。同时，一批厂商询问MIT，是否有某种措施能够维持源代码的完整性，好让X能够造福于所有对此感兴趣的组织机构。MIT同意了，不久之后，MIT X 协会成立，同时发布了源码，包括DEC对X的改善部分。此次X源码的发布确实是一个值得关注的事件。厂商们意识到，X已经有很高的价值了，需要避免某个公司获得对X的控制，更好的保护大家的心血，而维持X源码的开放是最重要的原则，同时MIT X 协会一直对X源码拥有版权，避免了X被私人商业公司拥有。
1988年，协会招募了一个高级开放者Keith Packard，他将重新实现X服务器的核心。现在，Packard在Linux图形栈领域已经众人皆知了。
尽管X在UNIX和Linux图形栈领域占据统治地位，但由于X的流行，基于X的、产生大量绘制请求的软件和大量的软件最终拖累了X本身。90年代，Linux快速流行起来，对于运行于同一机器上的X Server/client，开始使用X配置文件，同时X开始捆绑在很多Linux发行版上。对于本地显示来说，X基于网络的设计毫无用处，这一曾经大肆吹嘘的优点现在反而成为视频绘制的瓶颈。
这段时间，个人电脑的销售激增，专业图形显卡的复杂特性开始超越X的处理能力，更多高性能的显卡持续不断的开发出来。
转换表映射（以下简称TTM）的出现
2004年左右，一些Linux开发者开始对X缓慢的发展逐渐感到失望。1992年，他们开始转向OpenGL,一种图像渲染API，最初是用来显示2D和3D图形的（源于硅谷图形公司开发的）。经过几年X在显卡上绘制3D图形的尝试，最终没有一个方案可行。
然后在2007年，Thomas Hellstrom, Eric Anholt, 和 Dave Airlie共同开发了一个内存管理模块，他们称做TTM。TTM用于显存和系统内存之间的缓冲拷贝。当时在Linux社区引起了很大反响。它为那些对3D性能有严格要求的图形应用带来了希望。这个方法就是将内存缓冲区作为第一个类对象传递给应用程序使用，同时允许应用程序分配和处理内存缓冲区中的图形信息。TTM可以管理主机上所有应用程序的缓冲区，并且提供GPU和CPU之间的同步，这个过程是通过一个特殊信号fence完成的。当GPU完成对某个缓冲区的显示处理后，通过fence信号将此缓冲区的控制权交给此缓冲区对应的应用程序，此时CPU重新接管缓冲区。
平心而论，应用程序对GPU访问方式的标准化，TTM确实做了一个勇敢的尝试，它是Linux上针对所有显卡驱动的内存管理器，简言之，TTM尝试提供所有图形应用程序可能需要的所有操作。不幸的是，TTM代码量和API过于庞大，而每一个独立的开源驱动仅仅只需要API集合中的一个小子集。大量的API容易使开发者迷惑，他们需要决定选择使用哪个API。最大的抱怨是TTM还有一些性能问题，可能是由于CPU和GPU之间的信号同步机制（fence)导致，或者是缓冲区对象的拷贝效率太低。TTM可能确实要处理很多事情，不过这不能成为它变得缓慢的借口。
2008年，Reenter Keith Packard宣布了一个TTM的替代方案。Keith到目前为止还在Intel工作。得益于Eric开发TTM的经验教训，同时在Eric的帮助下，他们重写了TTM。新的API叫图形执行管理器（以下简称GEM），一般开发者通过API就能大致猜到下一步要做什么，相对于TTM庞大的API，开发者不会迷失于GEM的API中。
相对于TTM，GEM有很多提升，其中一个计较有意义的提升就是API接口的设计很严谨，同时TTM中伤脑筋的fence信号概念也去掉了。Keith和Eric让应用程序接管API之上的内存部分，GEM则专心处理GPU可访问的内存部分，并处理显卡执行的上下文信息。应用与内核空间的交互访是通过ioctl()调用，不存在TTM那种不停的缓冲区拷贝。GEM更像是一个面向流的API，而不是内存管理器。
GEM允许应用程序共享内存缓冲区，GPU处理的内存空间就不需要重新装载。以下是原始的发行说明：
“Gem为Linux操作系统提供简单的机制来管理图形数据和控制执行流程。很多内核子系统实现了这种机制。”
随着GEM在2008年5月的出现，给Linux的图形栈带来了更多的希望。GEM并不处理所有事情。例如，GPU执行的命令由设备对应驱动提供。因为Keith和Eric在Intel工作，GEM对Intel驱动支持的开源代码编写工作理所当然落在了他们身上。同时希望GEM能够支持更多其他的驱动，例如三个最大的显卡制造商。
然而，采用GEM的非intel显卡驱动很慢。一些迹象表明AMD驱动选择了一个“类似GEM和TTM管理器”的方案，预示着AMD并不愿意加入到GEM的阵营，GEM面临单枪匹马的危险。
TTM和GEM尝试在X中整合对GPU的操作以解决Linux图形栈上的3D加速问题。两者都是为了更好的提升不同图形库的显示性能，例如OpenGL(依赖于X), Qt(依赖于X)和GTK+（也是依赖于X)。问题是X处于所有图形库和内核之间，只有内核能够访问设备驱动，然后驱动才能访问到GPU。
X已经老掉牙了。X拥有数百万行代码，很多代码已经很陈旧，那是还没有GPU，没有专业的晶体管处理可编程着色技术或者旋转操作以及顶点翻转，既不知道高密度采样和用插值法减少反锯齿效果的概念，也不清楚如何创建极高精度的颜色空间。此时不同往日，X已经不能满足现在的需求了。
Wayland:一个新的显示管理器
2008年，一个叫Kristian H?gsberg 的软件工程师在波士顿的市郊上开着车，可能是去往工作的路上，亦或是回家，软件工程师正深入的思考着，有时他们会花费大量时间解决复杂的问题，将问题打散并进行重构。当他们工作疲劳休息时，会产生一些灵感，这种灵感往往能够为项目带来更大的突破。当人们在洗澡或者在厨房烹饪时，或者在驾驶途中，这种灵感更易产生。 当H?gsberg驱车于马萨诸塞州Wayland一个很小的村庄时，他的大脑中迸出一个想法并渐渐成型，这个想法用他自己的话说：
“核心思想是所有窗口被重定向，我们可以让所有客户端自己去渲染自己，然后传递一个缓冲句柄给显示服务器，显示服务器中的混合器完成窗口显示工作。其中一个目标就是让X服务器运行于Wayland上，首先支持全屏窗口（例如Xnest)，然后支持父窗口等，直到X被最终淘汰。”
他的想法是写一个全新的显示管理器，管理器可绕过X直接向内核发送3D显示请求。X自己就是显示管理器的一个客户端，正如以上作者所说，新的显示管理器取名为“Wayland”，以此表达对这个小镇的敬意。
这仅仅只是一个想法。很多人每天都会产生大量聪明的想法，但最终都被生活中的杂事所磨灭。 H?gsberg正从事于图形渲染库方面的工作，他大概觉得，如果应用程序都能直接访问GPU，没有X在中间搅局，那一切事情都变得简单了。他着手写代码解决这个问题。根据Intel的员工Keith Packard所说，两周后，H?gsber完成了雏形。
Wayland的一个关键特点是完成渲染工作的API完全不依赖X。为了保持兼容性，X服务器本身就是Wayland的客户端,所有X所做的渲染直接发给Wayland。像X一样，Wayland仅仅定义协议。Wayland的体系结构和X本身的特点，给X客户端的移植带来了很大便利，同时还兼容以前的X客户端程序。
Wayland显示管理器会使用内核中的GEM(图形执行管理器)、evdev(输入事件驱动)和kms(内核模式切换）。Wayland有自己的混合器，这与X形成鲜明的对比，X依赖外部的混合器处理显示相关的内存缓冲。
Wayland也会使用DRI2。Wayland混合器和Wayland客户端都能够访问屏幕显示相关的资源。当客户端更新了这个缓冲，混合器将更新桌面，并重绘屏幕。
Wayland确实解决了很多X无法解决的问题，大家对此项目感到兴奋，一群聪明的人正在实现它，并且Intel和redhat也在支持这个项目。
但是还有一些障碍需要克服。两个最大的障碍就是开发兼容NVIDIA和AMD的开源驱动。第三大显卡厂商Intel已经兼容了Wayland，因为GEM内核模块就是基于Intel驱动开发的。
谁会为Wayland更新AMD和NVIDIA的开源驱动？对开发者来说，Linux下开源显卡驱动的开发很折磨人，因为你没有完整的硬件规范手册，甚至什么资料都没有，只能通过枯燥的逆向工程获取显卡规范信息。
nouveau驱动就是一个很好的例子。当时，NVIDIA开发者放出话来，表示我们没有支持Wayland的计划。所有工作压向Linux社区，有时有一些厂商的支持，有时什么都没有。在nouveau项目中，开发者正通过逆向工程积极的开发NVIDIA驱动。一个叫做Renouveau(nouveau的逆向工程）的执行流程如下：
1. 记录MMIO寄存器的内容；
2. 绘制图形；
3. 记录寄存器中的新值；
然后向Renouveau工程的ftp服务器发送绘制前后内存转储的文本格式差异信息，这些文件是为以后的显卡分析做准备。
相对于NVIDIA，AMD这方面的工作进展更顺利。过去几年中，新成立的团队正在开发AMD的开源驱动，根据开发团队周期性发布的规范说明，各地开发者皆可持续驱动的研发。驱动名称是fglx(FireGL and Radeon for X）,Linux社区每月都可以从AMD获得显卡的最新信息。
Wayland在Linux图形栈方面很有优势。最近，Ubuntu计划在Wayland上使用他们自己的窗口管理器Unity。为了确保硬件驱动能在新的图形架构上发挥最大性能，Intel强力支持协助开发GEM，雇佣了Wayland的开发者们。
除此以外，图形领域正在两极分化。AMD和NVIDIA正忙于争夺市场份额的激烈竞争，开源社区的开发需求还排不上他们的议程。
Linux社区是基于协作来完成开发。多年以来，通过合作和开放，Linux急速发展，而Linux图形栈似乎不为所动。图形硬件厂商可选择是否向开源社区贡献力量，但很多厂商持不情愿开源的态度。那些拥有高性能图形显卡的厂商难道不想让他们的用户拥有最好的用户体验？将产品信息隐藏起来，这些难道不会伤及他们的产品线？可以毫无疑问的说-他们违反了开源精神。