getting x off the hardware
[[getting_x_off_the_hardware]] last edit on
May 8, 2006
11:26 AM
by mxt
原文链接：http://keithp.com/~keithp/talks/xserver_ols2004/
翻译人员：tclwp
Keith Packard
惠普剑桥研究实验室
keithp@keithp.com
X window系统通常是这样实现的：开发人员直接把操作视频硬件的代码插入X SERVER的代码中。视频模式选择代码和2D 加速代码通常在用户模式下执行并且直接和硬件通信。当前的X 代码架构提供了2D 和 3D 加速代码的分离，2D 代码在X SERVER中被执行，而3D 加速代码直接由应用程序执行，部分在用户空间部分在内核空间。视频模式选择功能仍旧在X SERVER中,人为造成了窗口系统的正确操作对3D 部分的依赖。这篇文章展示了为LINUX环境下的X设计的一个可行的架构，在这个环境下，图形加速的职责完全交给了现有的3D 用户/内核代码库，图形模式的选择功能被委派给了一个外部的库，因此，X SERVER成为了较简单的在前两者基础上的一层应用程序。各种在这样的架构上的相关技术（以及对输入设备进行支持的讨论）将在本文中讨论。
X11[SG92] SERVER的架构被设计来对输入和输出设备做很完善的操作支持。了解这些年 X 在这方面是如何演化的，将让我们容易领会本文中所提议的 X 的设计方向。
Digital QDSS (Dragon) 显示卡，是X11最早为其做2D加速的卡之一。这块卡有一个1024x768的帧缓冲，每个像素由4或8位表示。这个帧缓冲不能被CPU寻址，每个图形操作都由协处理器来做。该卡只有一种只支持它对应的主机专用显示器的视频模式。一个在内核中的原始的终端模拟器提供了启动机器必需的图形模式。
给处理器的图形命令被放到一个共享的DMA缓冲中并排队。当该缓冲区满时，X将在内核中阻塞以等待该区腾出空间给新的图形命令。
键盘和鼠标的支持由在内核和X SERVER间的另一个共享内存队列提供。内核建立了抽象事件结构体来表示从设备来的原始数据，并给机构体加上时间戳，放入共享队列。当新数据被插入时，一个文件描述符会收到一个信号以唤醒X SERVER，然后X SERVER可以直接检查共享内存段中的队列索引。X SERVER使用这种低开销的队列轮询来在每个X请求被执行后检查新的输入，以减少输入响应延迟。
硬件的光标支持在内核中处理，它的移动直接和鼠标驱动联系在一起，因此它能在中断发生时即时移动，造就了一个即使在CPU高负载时仍然能在X SERVER和其它应用程序中快速响应的光标。键盘控制器管理着从ASCII控制台模式到键转换的内在X模式。X server的非正常退出会留下一个在下面正常运作的控制台会话。
早期的SUN工作站有未加速的帧缓冲。像上面提到的QDSS卡，它们使用专用的显示器，不需要支持多种视频模式。当硬件进步时，他们的确有了可编程的时序硬件，但是从用户模式下的应用程序是不能配置它的。
X server 简单地把帧缓冲映射到它自己的地址空间并直接操作像素值。大约1990年前后，SUN 开始使用包含一个加速器的cgsix帧缓冲，不像QDSS卡，cgsix帧缓冲能被CPU所映射，并且加速器的文档不是SUN所发布。X11R4将这个卡作为一个简单的非智能的帧缓冲来支持。因为CPU访问这个帧缓冲的速度比SUN的早期非加速的帧缓冲设备慢，结果是慢得多的显示效果。
经过反汇编所提供的SUN窗口驱动程序，X 的作者能为X11R5建立一个加速的完全在用户模式下的X驱动程序。这个驱动不会在等待加速器结束任务时阻塞，它将自旋，不断轮询加速器直到它表明它已空闲。
内核以文件的形式（译注：是指/dev/mouse等吧）提供了对键盘鼠标的支持，从这些设备文件可以读取事件。缺乏可以表明"有有效输入到达"的共享内存机制意味着原始的驱动程序不能意识到输入事件的发生直到X server 轮询内核，这会占用许多重要的时间。因为内核没有对鼠标光标提供支持，X server 也负起了更新光标状态的责任，导致在CPU忙碌时很慢的鼠标移动跟踪（响应）。
为了改善这个问题，X server 被修改以在一个输入出现在设备文件描述符上时接收一个信号，并立即处理这个输入。当这个支持做好后，硬件光标也能在这时立即移动，使对鼠标的位置跟踪能力得到提高。然而，X server 负责把鼠标移动和硬件光标位置联系起来的事实意味着在高CPU负载时，硬件光标的移动会显著落后于鼠标的实际移动。
内核对键盘的支持，是以特殊的对键盘模式的设定来实现的：把键盘从ASCII字符输入模式变换成只报告原始按键变化事件的模式。因为内核不能跟踪现在键盘所处的状态， X server 不得不小心地在退出时把键盘设置回ASCII模式， 不然用户将再也无法和控制台交互了。
把所有的图形驱动放在用户空间排除了写一个内核驱动的必要性，但是这也使CPU要在图形引擎上忙等，影响了系统的整体性能。
修改内核来处理这些问题甚至还没被考虑；这些问题没影响到整个系统发挥功能，只是使系统不够完美。
随着以386为基础的PC硬件像日用品一样的普及，众多的厂家开始移植UNIX（以及类UNIX）到这类硬件上。移植最初没有包括X window 系统。一个完全不同的用户团体在没有操作系统厂商的支持下把X移植到这些系统上。
这些用户设法使X运行在早期的386硬件上的努力是使人印象深刻的壮举。他们必须在没有内核支持的情况下做所有的事情，这增加了工作的难度。
早期的PC图形卡只是一个适应当时图形操作要求的简单的帧缓冲，但是配置它们以产生正确的视频时序远不是那么简单的。因为显示器的品种很多，每种图形卡都是可编程的以产生多种视频时序。不正确的时序能破坏显示器。
在这些早期的386平台UNIX系统上的键盘支持非常像SUN操作系统所做的；键盘本质上是一个串行设备，它能被设置成两种状态：把按键变化转变成ASCII码的状态或报告它所输出的原始字节流的状态。
X server 将读取这些原始字节流并把它们翻译为 X 事件。再一次地，这里存在延迟：X server 不能立即地处理它们，只有当X server 轮询所有的输入来源：所有X 终端和所有的输入设备，才被处理。正像SUN驱动程序所做的，如果X server 没有把键盘设置回转换模式就终止了，那么键盘对终端来说就变得不可用。这个特殊的问题最终在LINUX中被凑合着解决了：加入了专门的键序列以重设键盘为转换模式。
对鼠标的支持实际上就是内核串口驱动解决的--PS/2鼠标还不存在，所以总线和串口鼠标被使用。X server 自己将打开这个设备，设置参数并分析鼠标的字节流。因为图形硬件没有光标支持，X server还要自己把光标画在屏幕上；这个操作得和渲染同步所以会有些延迟直到X server空闲时。
因为X server自己管理图形模式的配置，一次非正常的X server终止将使图形卡处于不正确的配置状态，使终端不可用了。类似地，键盘驱动将处于非转换模式，所以用户甚至不能操作计算机，只有重新启动机器。
X server被期望有和操作系统内核一样的稳定性；在X server中的bug将让系统像内核中有bug那样不可用。
随着图形加速被引入X86平台环境，X server扩展了它的用户模式操作以包含对图形加速器的操纵。正像上边所描述的Sun GX驱动，这些驱动没有得到内核的支持，被迫在硬件上忙等。
然而，不像GX硬件那样，PC的图形硬件和CPU间传输数据时会极大地占用PCI总线的带宽。不正确的硬件操作会造成PCI总线锁死，系统将不再能对网络和磁盘活动做出响应。不像上面提到过的简单的键盘模式转换问题，这个问题不能带入操作系统中。
因为图形设备没有内核驱动的支持，所以操作系统不能对它们的地址空间的映射进行管理。如果BIOS不正确地映射了图形设备，那么X server就得接下修正PCI映射空间的任务。从用户模式的应用程序去做PCI地址配置，只能在内核不具备任何动态管理能力的系统上工作。
如果机器有多个由标准VGA地址来控制的图形设备，X server将不得不飞快地操作这些PCI映射以确定当前是哪块卡在活动。
总的目标并不是建立一个可能的最好的系统，而是使代码尽可能地能够被移植，即使是系统架构有明显的不正确时。
Mesa项目是从为OpenGL API提供软件光栅开始的。通过对这被广泛接受的API提供免费的可用的实现，人们能在每台机器上运行3D程序，即使是那些没有自己的3D加速硬件的机器。当然，性能是一个重大的问题，特别是在3D世界的表现方法从彩色多边形转到纹理和复杂的光照环境时。
Mesa的开发者开始为几种有硬件文档的卡加入硬件支持。最初，有了全屏幕驱动程序，但到了最后DRI项目被启动以对整和到X WINDOWS系统中的多种3D应用程序提供支持。因为有支持多个无特权的3D应用程序同时进行安全的直接渲染的需要，DRI项目不得不包括一个内核驱动程序。这个驱动程序能管理设备映射、DMA和中断逻辑，甚至能在应用程序非正常退出时清理设备状态。
所有的3D命令被写入命令缓冲里，应用程序将其传递到内核，内核再将其传递到硬件设备；内核能在将命令放入传递到图形卡的队列前，对这些命令的内容进行确认。在许多方面，这样的系统和上面提到过的旧的Dragon X server相似。
这样的结果是有了一个在应用程序崩溃是仍然稳定的图形系统，提供了高性能和低CPU消耗。然而，DRI环境仍然依靠X server来管理图形模式选择和基本的设备输入。
自从原始的用户模式下的X server 架构发布以后，X server 在系统结构和性能特点上已经做了重大改进，使得了解这个系统是如何从头构建有了意义。对每个操作的支持代码将放在哪？这些问题将在后面一一述说，首先从图形加速开始，然后是视频模式选择，最后是输入设备（简要地）。
X总是直接访问系统的最底层来做2D图形加速。即使在QDSS上，在X server本身内部就对应构建了寄存器级的指令集。在某些系统上带有OpenGL[SAe99]的3D加速，这些系统需要两个分离的图形驱动，一个是给X server严格在2D模式内操作的，一个是在GL库内给3D操作的，对3D支持的进步对2D性能没有影响。
为了实际证明OpenGL在实现现有的X server 图形操作上多么有效率， Peter Nilsson 和 David Reveman 实现了Glitz库[NR04]，它支持建立在OpenGL API之上的Render API[Pac01]。在几个月内，他们设法以一种OpenGL实现为Cairo 图形库[WP03]在所有硬件上提供极大的加速。与之形成对比的是，在X 试验服务器中的Render实现使用了它自己的2D驱动程序，这东西看起来没有在加速方面做多少贡献，甚至从此扩展在3年半前最初设计到现在。只有几个驱动在加速方面做了半心半意的努力。
这里的目标是让X server 在所有的图形操作时使用OpenGL API。除掉X server自带的2D加速代码会减少开发负担。使用加速了的OpenGL 驱动将使现有的X驱动支持差劲的重要操作获得极大的性能提升。在这方面的工作，依赖于卓越的OpenGL驱动在缺乏下面的window 系统时的有效运作。幸运地，Mesa项目组正在忙于开发必需的下部构架。同时，利用依赖现有的X window系统的实现，开发能快速地推进，结果是有了另一个X server ，它只需要配置图形硬件和设置GL环境即可运行。
对于那些没有完整的OpenGL加速的卡，最大的目标就是提供类似DRI的内核功能性来支持DMA和中断，以使这些卡确实能支持的有用操作能有效实现。对于2D图形，需要加速的图形操作是那些被内存带宽所限制的--巨大的区域填充和复制。图形合成的特殊加速，在编写最少的代码的情况下有了巨大性能提升。过去写的那些在X协议的"麻烦角落"做了适当加速的数量壮观的代码，应该去除，这些"麻烦角落"留给软件，以使驱动实现的难度最小化。
这个架构由Eric Anholt 在他的kdriver基础上的Xati server[Anh04]上实现。使用现有的镭卡（Radeon）的DRI驱动，他开发了一个2D的X驱动，该驱动对通用的2D操作有合理的加速，包括X Render API这样的重要部分。这个驱动只使用了一小部分镭卡的DRI驱动，一个有深远意义的更小的内核驱动将满足一个基础性的实现。
总的来说，图形卡要在两个方面得到支持： 1.有一个在OpenGL基础上的X server 2.有一个在简单的可载入的驱动API基础上的仅有2D能力的X server
没有一个X server 内部架构上的决定改变现存的X和Render API作为对应用程序的基础的2D接口的自然性。使用现存的API的应用程序，当X server 为它们提供了更好的API实现时，将简单地发现它们自己运行得更有效率。这意味着应用程序不必转向非X的API以获得合理的加速。
然而，希望使用OpenGL的应用程序将发现一个被支持硬件的宽阔的范围，既然驱动开发者能选择编写OpenGL 或 2D驱动，并且不需要面对从2D驱动开始--只为支持X，这样的必要性。
在任何情况下，cairo图形库的使用使我们不必再受以上的问题的困扰，因为它支持X和GL，只需要在初始化时做适当的改变来在X和GL间选择。
视频模式选择的领域包含着许多不同的项目和利益；这个讨论的一个重要的目标就是鉴别出哪些领域是和X有关的和这些领域如何从大的项目中分离出来。
早在1984年当X开始设计的时候，图形设备是和与它们有紧密关系的对应的显示器装配在一起的。图形硬件必须小心地设计以输出合适的视频时序给与之配套的显示器；没有为适应不同的显示器准备的视频时序调整功能，每块显示卡只有一个显示器接口。
很快到了2004年，普通的显示卡有了两个甚至更多个的视频输出接口，带有标准的NTSC, SECAM 或 PAL电视视频格式。 动态调整显示环境以适应不同的使用方式的需求，在Apple OS X和Microsoft Windows 环境下被很好地支持，但是X 窗口系统还继承了许多从1984年就遗留下来的包袱。
PC上的X servers是这样适应简单的视频模式转换的：创建一个"虚拟"的桌面，至少和最大需要支持的视频模式一样大，使当前的模式只看到它的一部分，圈定显示范围使鼠标不走出屏幕边界。对于能够认可这种做法的用户，这提供了可用的，但不太完美的支持。然而，在大多数时候，为了能够着显示区外的屏幕内容只能通过移动鼠标是让人糊涂的。为了解决这个问题，X Resize and Rotate 扩展(RandR)[GP01]被设计出来，以提醒应用程序屏幕像素大小的变化并允许应用程序有目的地在可用的视频模式间作出选择。
RandR扩展很好地解决了只有单个显示器的简单情况，甚至允许当显示器被转变时在可用的所有视频模式间飞快地转换。然而，它不能解决支持多种不同的视频输出和动态管理它们之间的内容这样的更广泛的问题。
总的来说，X server 能正确地支持各种视频输出，甚至能选择把生成的输出放到一个大的显示区还是把显示分块到每个显示屏上。然而，没有能力动态调整这些配置，甚至不能自动地适应已经被检测到的环境变化。
随着2D性能不再是评测的重要工具，图形硬件厂商已经把焦点放到把他们的产品在视频输入/输出能力上差异化。这动态地扩展了用户的可选范围，并增加了操作系统对此进行支持的必要性。
随着可能的视频配置选项集在不断地扩展，似乎不能构建一个稳固的、标准的X扩展来满足所有的现存和将来的需要。因此，一个全功能的机制必须提供一些"后门"，通过"后门"显示驱动和用户代理能交流视频环境的信息，这些环境和窗口系统或在其中运行的应用程序没有直接的关系。
当前环境的另一个问题是，视频模式选择并不是只是对X 窗口系统才有要求。许多现存的其它图形系统都要依赖这些代码。现在，它已经被每种系统分别为每种视频卡做了实现。图形系统和视频卡的MxN种组合意味着只有少数几个系统对大范围内的视频卡有支持。为X以外的系统提供的支持是很少的。
X自己对整个系统提出了相关的适度的要求。X server 需要明白有哪些视频卡可用，对每块卡有哪些视频模式可用，如何选择当前的模式。在那种模式里可能有大量的和X server无关的信息；它确实只需要知道每个帧缓冲的像素尺寸，在每个显示器上像素的物理尺寸和显示器间的几何关系。关于哪个视频接口正在使用的细节，或者各个接口如何与帧缓冲间发生关系是不重要的。有关视频输入机制的信息与这更没多大关系。
X server 不需要解释视频模式环境的复杂性，它也不需要扮演环境管理者的角色。最合适的是，有一个外部的系统对此进行完全的控制，使X server能以它自己的简单方式进行交互。
这个外部的系统可以被实现为部分在内核中部分在用户模式下。这么做将让内核为那些没有在上电时自动合适地配置视频卡的系统，在引导时共享出视频模式选择的相同逻辑。另外，其它的图形系统将能够共享出相同的API给它们自己配置视频模式。
在过去的日子里，X环境只支持一种鼠标和一块（可能是国际化的）键盘。然而，这已经不符合现在的实际情况了。现在丰富的输入设备已经给X在配置和管理上造成了不小的麻烦。例如，X输入扩展在获得应用程序的广泛接受上失败了，当前的X环境转而仿效1984年的做法。
第一个要解决的问题，是当前X server自己负责分析来自各种各异的输入设备的原始数据流这种大杂烩式的设备支持方式。幸运地，内核已经解决了这个问题--新的建立在设备文件/dev/input基础上的驱动程序，提供了对所有设备的统一格式的描述和标准接口。可以直接了当地把X server 的相关功能建立在这些接口上。
无论如何，/dev/input/mice 这个接口在当今有重大的优点；它把所有的鼠标设备统一成一个简单的流，所以X server 不必处理设备的接入和脱离。所以，要转换输入机制，X server 首先必须学会利用这个。
鼠标（甚至还有键盘）能够容易地接上和脱离计算机。通过USB接口，系统能被自动地告知设备的来和去。这里缺的是一个把这些事件传递到X server 的方法，使X server 在适当的时候连接到新设备，告知X应用程序新设备已经可用，并把设备事件整合到中心光标或键盘事件流中。
硬件抽象层（HAL）[Zeu]项目，是设计来作为一个Linux热插拔系统和那些有兴趣跟踪连接到机器上的设备的状态的应用程序之间的中间层。通过提出这个机制，对X server 来说，发现和选择输入设备的复杂性能够被移入一个分离的系统，X server 只需要包含必需的代码来读取从HAL指定的输入设备来的事件。一个公开的问题是，是否这个思想被实现成X server 和 HAL 守护程序间的直接连接，或被实现成X 客户端通过到X server 的X协议接收HAL和传输设备的状态变化。
还有一个要做的改动是：扩展"X输入扩展组件"使其包含对新连接到机器上设备的和不可用的或已经脱离的设备等这些情况作出提醒。这个扩展已经允许可用的设备列表随着时间而改变，只欠东风的是当这些事件发生时通知应用程序的机制。在X server 的内部实现中，这个扩展面临着一些令人瞩目的更有挑战性的变革，因为当前的代码库假定可用的设备列表在X server 初始化时就是固定不变的。
当人们开始开发X时，每个显示系统都由一套键盘鼠标和一个专门配套的显示器组成。这种配置只用于单独的登录会话，并且输入设备从不移动。现在的情况已经全变了；输入设备可以来和去，计算机被接上投影仪，多个用户同时登录到一个X显示实例上。现代环境的动态本性要求X协议作出一些改进，或者变为新的形式，或者具有改进的扩展。
输入设备通常在物理位置上接近相应的输出设备。在一个具有多个输出设备和多个输入设备的系统上，没有机制来确定哪个设备在哪个地方。可能一些将来的先进的硬件会让总线拓扑包含这些设备的位置信息。
我们现在大概能做的最好是提供一个机制，在HAL数据库里给输入设备和输出设备的逻辑分组进行编码。这样，X server 就能在启动时从HAL接收可用的设备列表并能在系统硬件重新配置时接受正在进行的变化。
这种过分单纯化的做法的一个问题是：不允许输入设备从一组迁移到另一组；我们可以容易地想象，一个拿着无线指示设备的用户试图和一个"错的"X显示实例交互（会发生什么）。（在解决方案中需要）包含一些动态配置关联数据库的机制。
当许多系统没有能力增加或移除（多块）图形卡时，人们不是没有听说--许多掌上电脑支持CF视频适配器。在另一方面，几乎所有的系统确实支持实际的一个或多个显示设备的热插拔。许多系统甚至能检测显示器的接入或移除，使系统具有真正的自动检测和自动配置的能力。
当一个新的显示器被接上时，X server 需要改写自己的配置以包含新的显示器。当一组物理显示器被集合到一起作为一个单独的逻辑显示屏时，这种物理变化能以被 RandR 扩展支持的重设逻辑显示屏的大小之功能来响应。然而，如果每个物理显示屏以单独的逻辑显示屏的样子暴露给应用程序，那么X server 必须以某种方式适应新显示器的出现并把信息报告给应用程序。这需要编写一个扩展。
按照现存的X server 实现，这些改变有更多的戏剧性。这里再一次提到，有些根深蒂固的假定：在X控制下的硬件集合在X启动后将不会改变。解决这些问题将让X的开发者忙活一段时间。
一个LINUX很久以前就已经具有的能力是在许多虚拟终端会话间快速切换。X server 使用虚拟终端来保护系统控制台,在一个分离的终端上运行能保证只要简单地切换到相应的虚拟控制台就可以看到（使用）系统控制台。在此基础上，多个X servers 能在同一个硬件上启动，每个都运行在不同的虚拟控制台上并能快速地切换。
虚拟控制台机制只管理主要的图形设备和系统键盘。对其它图形和输入设备的管理纯粹依照惯例，结果是多个同时进行的X会话不容易被标准的X servers 架构所支持。X servers 的目标是对非主要的图形设备需要避免配置虚拟终端。然而，这也剥夺了那些设备支持多个会话的能力；不能在一个与任何虚拟终端都没有关联的设备上进行虚拟终端切换。
由于有HAL提供的哪些设备应被附属到一个单独的会话配置中的指示，X server 至少能适当地选择设备。类似地，X server应该能检测哪个设备是控制台的键盘并从那里管理虚拟终端。内核是否需要增加对其它图形/键盘设备的虚拟终端支持不是 X 需要回答的问题。
最后的问题是关于其它输入设备的；当切换虚拟控制台时，X server 按照惯例丢弃它到其它输入设备的连接，专横地打断了将要使用这个设备的应用程序。虽然这的确能工作，这造成了一个明显的可能性：一个在X server 内的错误将使设备处于连接状态并拒绝其它应用程序的访问。如果内核插手这个过程并在多个"消费者"间当虚拟终端的从属关系改变时自动地确定输入转到哪个"消费者"，情况可能会好些。
调整X窗口系统使其高效地工作并适合当代环境的要求将给X带来架构上的重大变化，然而在这个变革过程中，现存的应用程序将在很大程度上不受影响地继续运作。如果这不是真的，那么对现在窗口系统所做的改动的动机就值得怀疑。
把设备管理的责任迁移出X server ，交回给它本属于的内核部分，将使系统在稳定性、电源管理和在动态环境下的正确操作方面得到提高。改进后的系统性能将得到提高，因为内核比起用户模式能更好地利用硬件的优点。
在2D和3D应用程序间共享图形加速将减少为支持新的图形硬件所付出的努力。迁移视频模式选择的功能将让所有的图形系统利用它改进后的优点。这将允许一些在系统架构方面的有趣探索。
在定义精确的内核视频驱动架构方面还有许多重大的工作要做；这些驱动需要支持控制台操作，帧缓冲设备访问和直接渲染DRI或其它的3D加速。普通的内存分配机制看起来是必需的，连同指出一个合理的为视频模式选择而在内核和用户模式间的"劳动分配"。
其余还需要做的工作是解决在多个会话间共享多个设备时发生冲突的问题和创建一个机制以确定互有关系的输入和输出设备。
改进后的X窗口系统恢复了许多原始的X11 server架构的风味。具有在正确的结构层次上提供硬件支持这样的全景的一个系统，看来对相关的项目具有广泛的支持，使得未来变得光明。
[Anh04]
Eric Anholt.
High Performance X Servers in the Kdrive Architecture.
In FREENIX Track, 2004 Usenix Annual Technical Conference, Boston, MA, July 2004. USENIX.
[GP01]
Jim Gettys and Keith Packard.
The X Resize and Rotate Extension - RandR.
In FREENIX Track, 2001 Usenix Annual Technical Conference, Boston, MA, June 2001. USENIX.
[NR04]
Peter Nilsson and David Reveman.
Glitz: Hardware Accelerated Image Compositing using OpenGL.
In FREENIX Track, 2004 Usenix Annual Technical Conference, Boston, MA, July 2004. USENIX.
[Pac01]
Keith Packard.
Design and Implementation of the X Rendering Extension.
In FREENIX Track, 2001 Usenix Annual Technical Conference, Boston, MA, June 2001. USENIX.
[SAe99]
Mark Segal, Kurt Akeley, and Jon Leach (ed).
The OpenGL Graphics System: A Specification.
SGI, 1999.
[SG92]
Robert W. Scheifler and James Gettys.
X Window System.
Digital Press, third edition, 1992.
[WP03]
Carl Worth and Keith Packard.
Xr: Cross-device Rendering for Vector Graphics.
In Proceedings of the Ottawa Linux Symposium, Ottawa, ON, July 2003. OLS.
[Zeu]
David Zeuthen.
HAL Specification 0.2.
http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html
翻译人员：tclwp
让X硬件无关
Keith Packard
惠普剑桥研究实验室
keithp@keithp.com
摘要：
X window系统通常是这样实现的：开发人员直接把操作视频硬件的代码插入X SERVER的代码中。视频模式选择代码和2D 加速代码通常在用户模式下执行并且直接和硬件通信。当前的X 代码架构提供了2D 和 3D 加速代码的分离，2D 代码在X SERVER中被执行，而3D 加速代码直接由应用程序执行，部分在用户空间部分在内核空间。视频模式选择功能仍旧在X SERVER中,人为造成了窗口系统的正确操作对3D 部分的依赖。这篇文章展示了为LINUX环境下的X设计的一个可行的架构，在这个环境下，图形加速的职责完全交给了现有的3D 用户/内核代码库，图形模式的选择功能被委派给了一个外部的库，因此，X SERVER成为了较简单的在前两者基础上的一层应用程序。各种在这样的架构上的相关技术（以及对输入设备进行支持的讨论）将在本文中讨论。
1 历史：
X11[SG92] SERVER的架构被设计来对输入和输出设备做很完善的操作支持。了解这些年 X 在这方面是如何演化的，将让我们容易领会本文中所提议的 X 的设计方向。
1.1 最初的 X 架构：
Digital QDSS (Dragon) 显示卡，是X11最早为其做2D加速的卡之一。这块卡有一个1024x768的帧缓冲，每个像素由4或8位表示。这个帧缓冲不能被CPU寻址，每个图形操作都由协处理器来做。该卡只有一种只支持它对应的主机专用显示器的视频模式。一个在内核中的原始的终端模拟器提供了启动机器必需的图形模式。
给处理器的图形命令被放到一个共享的DMA缓冲中并排队。当该缓冲区满时，X将在内核中阻塞以等待该区腾出空间给新的图形命令。
键盘和鼠标的支持由在内核和X SERVER间的另一个共享内存队列提供。内核建立了抽象事件结构体来表示从设备来的原始数据，并给机构体加上时间戳，放入共享队列。当新数据被插入时，一个文件描述符会收到一个信号以唤醒X SERVER，然后X SERVER可以直接检查共享内存段中的队列索引。X SERVER使用这种低开销的队列轮询来在每个X请求被执行后检查新的输入，以减少输入响应延迟。
硬件的光标支持在内核中处理，它的移动直接和鼠标驱动联系在一起，因此它能在中断发生时即时移动，造就了一个即使在CPU高负载时仍然能在X SERVER和其它应用程序中快速响应的光标。键盘控制器管理着从ASCII控制台模式到键转换的内在X模式。X server的非正常退出会留下一个在下面正常运作的控制台会话。
1.2 光滑的斜面：
早期的SUN工作站有未加速的帧缓冲。像上面提到的QDSS卡，它们使用专用的显示器，不需要支持多种视频模式。当硬件进步时，他们的确有了可编程的时序硬件，但是从用户模式下的应用程序是不能配置它的。
X server 简单地把帧缓冲映射到它自己的地址空间并直接操作像素值。大约1990年前后，SUN 开始使用包含一个加速器的cgsix帧缓冲，不像QDSS卡，cgsix帧缓冲能被CPU所映射，并且加速器的文档不是SUN所发布。X11R4将这个卡作为一个简单的非智能的帧缓冲来支持。因为CPU访问这个帧缓冲的速度比SUN的早期非加速的帧缓冲设备慢，结果是慢得多的显示效果。
经过反汇编所提供的SUN窗口驱动程序，X 的作者能为X11R5建立一个加速的完全在用户模式下的X驱动程序。这个驱动不会在等待加速器结束任务时阻塞，它将自旋，不断轮询加速器直到它表明它已空闲。
内核以文件的形式（译注：是指/dev/mouse等吧）提供了对键盘鼠标的支持，从这些设备文件可以读取事件。缺乏可以表明"有有效输入到达"的共享内存机制意味着原始的驱动程序不能意识到输入事件的发生直到X server 轮询内核，这会占用许多重要的时间。因为内核没有对鼠标光标提供支持，X server 也负起了更新光标状态的责任，导致在CPU忙碌时很慢的鼠标移动跟踪（响应）。
为了改善这个问题，X server 被修改以在一个输入出现在设备文件描述符上时接收一个信号，并立即处理这个输入。当这个支持做好后，硬件光标也能在这时立即移动，使对鼠标的位置跟踪能力得到提高。然而，X server 负责把鼠标移动和硬件光标位置联系起来的事实意味着在高CPU负载时，硬件光标的移动会显著落后于鼠标的实际移动。
内核对键盘的支持，是以特殊的对键盘模式的设定来实现的：把键盘从ASCII字符输入模式变换成只报告原始按键变化事件的模式。因为内核不能跟踪现在键盘所处的状态， X server 不得不小心地在退出时把键盘设置回ASCII模式， 不然用户将再也无法和控制台交互了。
把所有的图形驱动放在用户空间排除了写一个内核驱动的必要性，但是这也使CPU要在图形引擎上忙等，影响了系统的整体性能。
修改内核来处理这些问题甚至还没被考虑；这些问题没影响到整个系统发挥功能，只是使系统不够完美。
1.3 跳舞的熊：
随着以386为基础的PC硬件像日用品一样的普及，众多的厂家开始移植UNIX（以及类UNIX）到这类硬件上。移植最初没有包括X window 系统。一个完全不同的用户团体在没有操作系统厂商的支持下把X移植到这些系统上。
这些用户设法使X运行在早期的386硬件上的努力是使人印象深刻的壮举。他们必须在没有内核支持的情况下做所有的事情，这增加了工作的难度。
早期的PC图形卡只是一个适应当时图形操作要求的简单的帧缓冲，但是配置它们以产生正确的视频时序远不是那么简单的。因为显示器的品种很多，每种图形卡都是可编程的以产生多种视频时序。不正确的时序能破坏显示器。
在这些早期的386平台UNIX系统上的键盘支持非常像SUN操作系统所做的；键盘本质上是一个串行设备，它能被设置成两种状态：把按键变化转变成ASCII码的状态或报告它所输出的原始字节流的状态。
X server 将读取这些原始字节流并把它们翻译为 X 事件。再一次地，这里存在延迟：X server 不能立即地处理它们，只有当X server 轮询所有的输入来源：所有X 终端和所有的输入设备，才被处理。正像SUN驱动程序所做的，如果X server 没有把键盘设置回转换模式就终止了，那么键盘对终端来说就变得不可用。这个特殊的问题最终在LINUX中被凑合着解决了：加入了专门的键序列以重设键盘为转换模式。
对鼠标的支持实际上就是内核串口驱动解决的--PS/2鼠标还不存在，所以总线和串口鼠标被使用。X server 自己将打开这个设备，设置参数并分析鼠标的字节流。因为图形硬件没有光标支持，X server还要自己把光标画在屏幕上；这个操作得和渲染同步所以会有些延迟直到X server空闲时。
因为X server自己管理图形模式的配置，一次非正常的X server终止将使图形卡处于不正确的配置状态，使终端不可用了。类似地，键盘驱动将处于非转换模式，所以用户甚至不能操作计算机，只有重新启动机器。
X server被期望有和操作系统内核一样的稳定性；在X server中的bug将让系统像内核中有bug那样不可用。
1.4 绝望的深坑：
随着图形加速被引入X86平台环境，X server扩展了它的用户模式操作以包含对图形加速器的操纵。正像上边所描述的Sun GX驱动，这些驱动没有得到内核的支持，被迫在硬件上忙等。
然而，不像GX硬件那样，PC的图形硬件和CPU间传输数据时会极大地占用PCI总线的带宽。不正确的硬件操作会造成PCI总线锁死，系统将不再能对网络和磁盘活动做出响应。不像上面提到过的简单的键盘模式转换问题，这个问题不能带入操作系统中。
因为图形设备没有内核驱动的支持，所以操作系统不能对它们的地址空间的映射进行管理。如果BIOS不正确地映射了图形设备，那么X server就得接下修正PCI映射空间的任务。从用户模式的应用程序去做PCI地址配置，只能在内核不具备任何动态管理能力的系统上工作。
如果机器有多个由标准VGA地址来控制的图形设备，X server将不得不飞快地操作这些PCI映射以确定当前是哪块卡在活动。
总的目标并不是建立一个可能的最好的系统，而是使代码尽可能地能够被移植，即使是系统架构有明显的不正确时。
1.5 希望的曙光
Mesa项目是从为OpenGL API提供软件光栅开始的。通过对这被广泛接受的API提供免费的可用的实现，人们能在每台机器上运行3D程序，即使是那些没有自己的3D加速硬件的机器。当然，性能是一个重大的问题，特别是在3D世界的表现方法从彩色多边形转到纹理和复杂的光照环境时。
Mesa的开发者开始为几种有硬件文档的卡加入硬件支持。最初，有了全屏幕驱动程序，但到了最后DRI项目被启动以对整和到X WINDOWS系统中的多种3D应用程序提供支持。因为有支持多个无特权的3D应用程序同时进行安全的直接渲染的需要，DRI项目不得不包括一个内核驱动程序。这个驱动程序能管理设备映射、DMA和中断逻辑，甚至能在应用程序非正常退出时清理设备状态。
所有的3D命令被写入命令缓冲里，应用程序将其传递到内核，内核再将其传递到硬件设备；内核能在将命令放入传递到图形卡的队列前，对这些命令的内容进行确认。在许多方面，这样的系统和上面提到过的旧的Dragon X server相似。
这样的结果是有了一个在应用程序崩溃是仍然稳定的图形系统，提供了高性能和低CPU消耗。然而，DRI环境仍然依靠X server来管理图形模式选择和基本的设备输入。
2 后面几节的说明
自从原始的用户模式下的X server 架构发布以后，X server 在系统结构和性能特点上已经做了重大改进，使得了解这个系统是如何从头构建有了意义。对每个操作的支持代码将放在哪？这些问题将在后面一一述说，首先从图形加速开始，然后是视频模式选择，最后是输入设备（简要地）。
3 图形加速
X总是直接访问系统的最底层来做2D图形加速。即使在QDSS上，在X server本身内部就对应构建了寄存器级的指令集。在某些系统上带有OpenGL[SAe99]的3D加速，这些系统需要两个分离的图形驱动，一个是给X server严格在2D模式内操作的，一个是在GL库内给3D操作的，对3D支持的进步对2D性能没有影响。
为了实际证明OpenGL在实现现有的X server 图形操作上多么有效率， Peter Nilsson 和 David Reveman 实现了Glitz库[NR04]，它支持建立在OpenGL API之上的Render API[Pac01]。在几个月内，他们设法以一种OpenGL实现为Cairo 图形库[WP03]在所有硬件上提供极大的加速。与之形成对比的是，在X 试验服务器中的Render实现使用了它自己的2D驱动程序，这东西看起来没有在加速方面做多少贡献，甚至从此扩展在3年半前最初设计到现在。只有几个驱动在加速方面做了半心半意的努力。
这里的目标是让X server 在所有的图形操作时使用OpenGL API。除掉X server自带的2D加速代码会减少开发负担。使用加速了的OpenGL 驱动将使现有的X驱动支持差劲的重要操作获得极大的性能提升。在这方面的工作，依赖于卓越的OpenGL驱动在缺乏下面的window 系统时的有效运作。幸运地，Mesa项目组正在忙于开发必需的下部构架。同时，利用依赖现有的X window系统的实现，开发能快速地推进，结果是有了另一个X server ，它只需要配置图形硬件和设置GL环境即可运行。
对于那些没有完整的OpenGL加速的卡，最大的目标就是提供类似DRI的内核功能性来支持DMA和中断，以使这些卡确实能支持的有用操作能有效实现。对于2D图形，需要加速的图形操作是那些被内存带宽所限制的--巨大的区域填充和复制。图形合成的特殊加速，在编写最少的代码的情况下有了巨大性能提升。过去写的那些在X协议的"麻烦角落"做了适当加速的数量壮观的代码，应该去除，这些"麻烦角落"留给软件，以使驱动实现的难度最小化。
这个架构由Eric Anholt 在他的kdriver基础上的Xati server[Anh04]上实现。使用现有的镭卡（Radeon）的DRI驱动，他开发了一个2D的X驱动，该驱动对通用的2D操作有合理的加速，包括X Render API这样的重要部分。这个驱动只使用了一小部分镭卡的DRI驱动，一个有深远意义的更小的内核驱动将满足一个基础性的实现。
总的来说，图形卡要在两个方面得到支持： 1.有一个在OpenGL基础上的X server 2.有一个在简单的可载入的驱动API基础上的仅有2D能力的X server
3.1 和应用程序有关的问题
没有一个X server 内部架构上的决定改变现存的X和Render API作为对应用程序的基础的2D接口的自然性。使用现存的API的应用程序，当X server 为它们提供了更好的API实现时，将简单地发现它们自己运行得更有效率。这意味着应用程序不必转向非X的API以获得合理的加速。
然而，希望使用OpenGL的应用程序将发现一个被支持硬件的宽阔的范围，既然驱动开发者能选择编写OpenGL 或 2D驱动，并且不需要面对从2D驱动开始--只为支持X，这样的必要性。
在任何情况下，cairo图形库的使用使我们不必再受以上的问题的困扰，因为它支持X和GL，只需要在初始化时做适当的改变来在X和GL间选择。
4 视频模式配置
视频模式选择的领域包含着许多不同的项目和利益；这个讨论的一个重要的目标就是鉴别出哪些领域是和X有关的和这些领域如何从大的项目中分离出来。
4.1 问题概览
早在1984年当X开始设计的时候，图形设备是和与它们有紧密关系的对应的显示器装配在一起的。图形硬件必须小心地设计以输出合适的视频时序给与之配套的显示器；没有为适应不同的显示器准备的视频时序调整功能，每块显示卡只有一个显示器接口。
很快到了2004年，普通的显示卡有了两个甚至更多个的视频输出接口，带有标准的NTSC, SECAM 或 PAL电视视频格式。 动态调整显示环境以适应不同的使用方式的需求，在Apple OS X和Microsoft Windows 环境下被很好地支持，但是X 窗口系统还继承了许多从1984年就遗留下来的包袱。
4.2 X试图修补问题
PC上的X servers是这样适应简单的视频模式转换的：创建一个"虚拟"的桌面，至少和最大需要支持的视频模式一样大，使当前的模式只看到它的一部分，圈定显示范围使鼠标不走出屏幕边界。对于能够认可这种做法的用户，这提供了可用的，但不太完美的支持。然而，在大多数时候，为了能够着显示区外的屏幕内容只能通过移动鼠标是让人糊涂的。为了解决这个问题，X Resize and Rotate 扩展(RandR)[GP01]被设计出来，以提醒应用程序屏幕像素大小的变化并允许应用程序有目的地在可用的视频模式间作出选择。
RandR扩展很好地解决了只有单个显示器的简单情况，甚至允许当显示器被转变时在可用的所有视频模式间飞快地转换。然而，它不能解决支持多种不同的视频输出和动态管理它们之间的内容这样的更广泛的问题。
总的来说，X server 能正确地支持各种视频输出，甚至能选择把生成的输出放到一个大的显示区还是把显示分块到每个显示屏上。然而，没有能力动态调整这些配置，甚至不能自动地适应已经被检测到的环境变化。
4.3 X只是计算机领域的一部分
随着2D性能不再是评测的重要工具，图形硬件厂商已经把焦点放到把他们的产品在视频输入/输出能力上差异化。这动态地扩展了用户的可选范围，并增加了操作系统对此进行支持的必要性。
随着可能的视频配置选项集在不断地扩展，似乎不能构建一个稳固的、标准的X扩展来满足所有的现存和将来的需要。因此，一个全功能的机制必须提供一些"后门"，通过"后门"显示驱动和用户代理能交流视频环境的信息，这些环境和窗口系统或在其中运行的应用程序没有直接的关系。
当前环境的另一个问题是，视频模式选择并不是只是对X 窗口系统才有要求。许多现存的其它图形系统都要依赖这些代码。现在，它已经被每种系统分别为每种视频卡做了实现。图形系统和视频卡的MxN种组合意味着只有少数几个系统对大范围内的视频卡有支持。为X以外的系统提供的支持是很少的。
4.4 这里是谁负责的，无论如何？
X自己对整个系统提出了相关的适度的要求。X server 需要明白有哪些视频卡可用，对每块卡有哪些视频模式可用，如何选择当前的模式。在那种模式里可能有大量的和X server无关的信息；它确实只需要知道每个帧缓冲的像素尺寸，在每个显示器上像素的物理尺寸和显示器间的几何关系。关于哪个视频接口正在使用的细节，或者各个接口如何与帧缓冲间发生关系是不重要的。有关视频输入机制的信息与这更没多大关系。
X server 不需要解释视频模式环境的复杂性，它也不需要扮演环境管理者的角色。最合适的是，有一个外部的系统对此进行完全的控制，使X server能以它自己的简单方式进行交互。
这个外部的系统可以被实现为部分在内核中部分在用户模式下。这么做将让内核为那些没有在上电时自动合适地配置视频卡的系统，在引导时共享出视频模式选择的相同逻辑。另外，其它的图形系统将能够共享出相同的API给它们自己配置视频模式。
5 输入设备支持
在过去的日子里，X环境只支持一种鼠标和一块（可能是国际化的）键盘。然而，这已经不符合现在的实际情况了。现在丰富的输入设备已经给X在配置和管理上造成了不小的麻烦。例如，X输入扩展在获得应用程序的广泛接受上失败了，当前的X环境转而仿效1984年的做法。
5.1 统一设备访问
第一个要解决的问题，是当前X server自己负责分析来自各种各异的输入设备的原始数据流这种大杂烩式的设备支持方式。幸运地，内核已经解决了这个问题--新的建立在设备文件/dev/input基础上的驱动程序，提供了对所有设备的统一格式的描述和标准接口。可以直接了当地把X server 的相关功能建立在这些接口上。
无论如何，/dev/input/mice 这个接口在当今有重大的优点；它把所有的鼠标设备统一成一个简单的流，所以X server 不必处理设备的接入和脱离。所以，要转换输入机制，X server 首先必须学会利用这个。
5.2 热插拔和硬件抽象层（HAL）
鼠标（甚至还有键盘）能够容易地接上和脱离计算机。通过USB接口，系统能被自动地告知设备的来和去。这里缺的是一个把这些事件传递到X server 的方法，使X server 在适当的时候连接到新设备，告知X应用程序新设备已经可用，并把设备事件整合到中心光标或键盘事件流中。
硬件抽象层（HAL）[Zeu]项目，是设计来作为一个Linux热插拔系统和那些有兴趣跟踪连接到机器上的设备的状态的应用程序之间的中间层。通过提出这个机制，对X server 来说，发现和选择输入设备的复杂性能够被移入一个分离的系统，X server 只需要包含必需的代码来读取从HAL指定的输入设备来的事件。一个公开的问题是，是否这个思想被实现成X server 和 HAL 守护程序间的直接连接，或被实现成X 客户端通过到X server 的X协议接收HAL和传输设备的状态变化。
还有一个要做的改动是：扩展"X输入扩展组件"使其包含对新连接到机器上设备的和不可用的或已经脱离的设备等这些情况作出提醒。这个扩展已经允许可用的设备列表随着时间而改变，只欠东风的是当这些事件发生时通知应用程序的机制。在X server 的内部实现中，这个扩展面临着一些令人瞩目的更有挑战性的变革，因为当前的代码库假定可用的设备列表在X server 初始化时就是固定不变的。
6 迁移设备
当人们开始开发X时，每个显示系统都由一套键盘鼠标和一个专门配套的显示器组成。这种配置只用于单独的登录会话，并且输入设备从不移动。现在的情况已经全变了；输入设备可以来和去，计算机被接上投影仪，多个用户同时登录到一个X显示实例上。现代环境的动态本性要求X协议作出一些改进，或者变为新的形式，或者具有改进的扩展。
6.1 这是谁的鼠标？
输入设备通常在物理位置上接近相应的输出设备。在一个具有多个输出设备和多个输入设备的系统上，没有机制来确定哪个设备在哪个地方。可能一些将来的先进的硬件会让总线拓扑包含这些设备的位置信息。
我们现在大概能做的最好是提供一个机制，在HAL数据库里给输入设备和输出设备的逻辑分组进行编码。这样，X server 就能在启动时从HAL接收可用的设备列表并能在系统硬件重新配置时接受正在进行的变化。
这种过分单纯化的做法的一个问题是：不允许输入设备从一组迁移到另一组；我们可以容易地想象，一个拿着无线指示设备的用户试图和一个"错的"X显示实例交互（会发生什么）。（在解决方案中需要）包含一些动态配置关联数据库的机制。
6.2 热插拔视频硬件
当许多系统没有能力增加或移除（多块）图形卡时，人们不是没有听说--许多掌上电脑支持CF视频适配器。在另一方面，几乎所有的系统确实支持实际的一个或多个显示设备的热插拔。许多系统甚至能检测显示器的接入或移除，使系统具有真正的自动检测和自动配置的能力。
当一个新的显示器被接上时，X server 需要改写自己的配置以包含新的显示器。当一组物理显示器被集合到一起作为一个单独的逻辑显示屏时，这种物理变化能以被 RandR 扩展支持的重设逻辑显示屏的大小之功能来响应。然而，如果每个物理显示屏以单独的逻辑显示屏的样子暴露给应用程序，那么X server 必须以某种方式适应新显示器的出现并把信息报告给应用程序。这需要编写一个扩展。
按照现存的X server 实现，这些改变有更多的戏剧性。这里再一次提到，有些根深蒂固的假定：在X控制下的硬件集合在X启动后将不会改变。解决这些问题将让X的开发者忙活一段时间。
6.3 虚拟终端切换
一个LINUX很久以前就已经具有的能力是在许多虚拟终端会话间快速切换。X server 使用虚拟终端来保护系统控制台,在一个分离的终端上运行能保证只要简单地切换到相应的虚拟控制台就可以看到（使用）系统控制台。在此基础上，多个X servers 能在同一个硬件上启动，每个都运行在不同的虚拟控制台上并能快速地切换。
虚拟控制台机制只管理主要的图形设备和系统键盘。对其它图形和输入设备的管理纯粹依照惯例，结果是多个同时进行的X会话不容易被标准的X servers 架构所支持。X servers 的目标是对非主要的图形设备需要避免配置虚拟终端。然而，这也剥夺了那些设备支持多个会话的能力；不能在一个与任何虚拟终端都没有关联的设备上进行虚拟终端切换。
由于有HAL提供的哪些设备应被附属到一个单独的会话配置中的指示，X server 至少能适当地选择设备。类似地，X server应该能检测哪个设备是控制台的键盘并从那里管理虚拟终端。内核是否需要增加对其它图形/键盘设备的虚拟终端支持不是 X 需要回答的问题。
最后的问题是关于其它输入设备的；当切换虚拟控制台时，X server 按照惯例丢弃它到其它输入设备的连接，专横地打断了将要使用这个设备的应用程序。虽然这的确能工作，这造成了一个明显的可能性：一个在X server 内的错误将使设备处于连接状态并拒绝其它应用程序的访问。如果内核插手这个过程并在多个"消费者"间当虚拟终端的从属关系改变时自动地确定输入转到哪个"消费者"，情况可能会好些。
7 结论
调整X窗口系统使其高效地工作并适合当代环境的要求将给X带来架构上的重大变化，然而在这个变革过程中，现存的应用程序将在很大程度上不受影响地继续运作。如果这不是真的，那么对现在窗口系统所做的改动的动机就值得怀疑。
把设备管理的责任迁移出X server ，交回给它本属于的内核部分，将使系统在稳定性、电源管理和在动态环境下的正确操作方面得到提高。改进后的系统性能将得到提高，因为内核比起用户模式能更好地利用硬件的优点。
在2D和3D应用程序间共享图形加速将减少为支持新的图形硬件所付出的努力。迁移视频模式选择的功能将让所有的图形系统利用它改进后的优点。这将允许一些在系统架构方面的有趣探索。
在定义精确的内核视频驱动架构方面还有许多重大的工作要做；这些驱动需要支持控制台操作，帧缓冲设备访问和直接渲染DRI或其它的3D加速。普通的内存分配机制看起来是必需的，连同指出一个合理的为视频模式选择而在内核和用户模式间的"劳动分配"。
其余还需要做的工作是解决在多个会话间共享多个设备时发生冲突的问题和创建一个机制以确定互有关系的输入和输出设备。
改进后的X窗口系统恢复了许多原始的X11 server架构的风味。具有在正确的结构层次上提供硬件支持这样的全景的一个系统，看来对相关的项目具有广泛的支持，使得未来变得光明。
参考文献：
[Anh04]
Eric Anholt.
High Performance X Servers in the Kdrive Architecture.
In FREENIX Track, 2004 Usenix Annual Technical Conference, Boston, MA, July 2004. USENIX.
[GP01]
Jim Gettys and Keith Packard.
The X Resize and Rotate Extension - RandR.
In FREENIX Track, 2001 Usenix Annual Technical Conference, Boston, MA, June 2001. USENIX.
[NR04]
Peter Nilsson and David Reveman.
Glitz: Hardware Accelerated Image Compositing using OpenGL.
In FREENIX Track, 2004 Usenix Annual Technical Conference, Boston, MA, July 2004. USENIX.
[Pac01]
Keith Packard.
Design and Implementation of the X Rendering Extension.
In FREENIX Track, 2001 Usenix Annual Technical Conference, Boston, MA, June 2001. USENIX.
[SAe99]
Mark Segal, Kurt Akeley, and Jon Leach (ed).
The OpenGL Graphics System: A Specification.
SGI, 1999.
[SG92]
Robert W. Scheifler and James Gettys.
X Window System.
Digital Press, third edition, 1992.
[WP03]
Carl Worth and Keith Packard.
Xr: Cross-device Rendering for Vector Graphics.
In Proceedings of the Ottawa Linux Symposium, Ottawa, ON, July 2003. OLS.
[Zeu]
David Zeuthen.
HAL Specification 0.2.
http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html