Mir
Canonical 2013年3月宣布开发自己的显示服务器 Mir之后,引发了开源界的大量谴责,很多人指责Canonical为什么不采用被设计用来取代X11的Wayland,Wayland的开发者也表示Wayland完全能够满足Canonical的需求,指责Canonical搞分裂的行为。
而 Canonical 则表示现在的 X 以及未来的 Wayland 无法满足未来横跨桌面、手机、平板和电视的发展策略。Ubuntu 社区经理 Jono Bacon 认为这两者都包含了太多 Ubuntu 策略中用不到的功能。Canonical曾经考虑过Wayland,但当该公司重心转到移动平台之后Wayland的缺陷就显而易见了,Wayland可以支持移动,但需要大量的工作,Canonical的时间不多,它等不起了。于是 Canonical 决定开发自己的显示服务器 Mir,Mir 将助力未来自家使用 QT/QML 技术构建桌面环境 Unity Next。
目前Mir仍然在开发之中,,它将支持Android图形驱动和Linux开源图形驱动,Canonical正向硬件厂商施压要求厂家的商业闭源驱动支持 Mir。目前Mir仅能在开源驱动下使用,且依赖 Canonical fork 出来,未提及也未打算合并至上游 Mesa 的 EGL DRI2 代码。
Mir 目前没有任何工具集支持,而当下 Wayland 已经得到 GTK3 及 Qt5 的明确支持,上游桌面环境及应用程序的迁移正在逐步进行。Canonical称,Mir将兼容X11应用,原生支持GTK3和Qt/QML工具。Mir将应用于从手机到桌面的所有平台。
Wayland
Wayland 是2008年由 Intel 开放源代码技术中心 的成员 Kristian Høgsberg 所发起的一个桌面的显示服务器协议和在Linux上实现这个协议的软件库。它是一个自由软件专案,采用MIT许可证释出。作者声称“每一个显示画面皆是完美的,我的意思是应用程序将能充分地去控制图形的显示,使我们完全无法察觉任何的撕裂、延迟、重画及闪烁”。Wayland使得Compositor能够与应用程序和视频硬件直接交互。 应用程序在它们自己的缓冲区中进行图形渲染。这样一来,窗口管理器就变成了一个显示管理服务,专门负责渲染那些屏幕上的程序。这比X Window系统中的窗口管理器要更简单,高效。
设计
Wayland 运用既有的 Linux 核心技术,像是 Direct Rendering Manager (DRM), kernel mode-setting (KMS) 以及 Graphics Execution Manager (GEM) 以提供一个最小化的显示管理服务。Wayland 混合器 (compositor) 在 2010 年 6 月已从桌面常用的 OpenGL 改为 OpenGL ES。这个专案也开发支援 Wayland 显示的 Qt,而不需要 X。大部分应用程式都有望获得透过函式库,无需修改程式即可支援 Wayland。
近些年来,GNU/Linux 桌面图形开发者从X server中移除了一大堆的与渲染有关的接口到内核中。现在,已经有许多功能被移入内核(内存管理,任务调度,模式设置(KMS)等等)或是程序库(cario,pixman,freetype,fontconfig,pango等等),所以窗口系统需要做的事情大大减少了。但是 X11 协议十分巨大,庞杂,并且它包括了许多已经过时的模块。虽然开发者们为了使 X server 适应现代化的计算机体系结构而开发出了 XRandR,XRender,COMPOSITE等一些额外扩展,但这终究是治标不治本,同时这也会增加维护的难度。 Wayland也包括了一个协议(近乎完成),但与X server不同的是 Wayland只做它必须要做到事情。下面我们以"鼠标点击按钮引发按钮更新动作"来说明一下 Wayland 和 X server 的区别:
在 X 中:
![220px-X-architecture.png 220px-X-architecture.png](http://static.oschina.net/uploads/img/201306/22210444_hQ74.jpg)
内核捕获鼠标点击事件并发送给 X server。
X server 会计算该把这一事件发送给哪个窗口(事实上,窗口位置是由Compositor控制的,X server并不能够正确的计算Compositor做过特效变化之后的按钮的正确位置)。
应用程序对此事件进行处理(将引发按钮更新动作)。但是,在此之前它得向X server发送绘制请求。
X server接收到这条绘制请求,然后把它发给视频驱动来渲染。X 还计算了更新区域,并且这条"垃圾信息"发送给了Compositor。
这时,Compositor 知道它必须要重新合成屏幕上的一块区域。当然,这还是要向X server发送绘制请求的。
开始绘制。但是X server 还会去做一些不必要的本职工作(窗口重叠计算,窗口剪裁计算等)。
在 Wayland 中:
![220px-Wayland-architecture.png 220px-Wayland-architecture.png](http://static.oschina.net/uploads/img/201306/22210444_KUM5.jpg)
内核捕获鼠标点击事件并发送给 Wayland Compositor。
由于是直接发给Compositor的,所以Wayland会正确地计算出按钮的位置。同时它会把这一事件发送给按钮所在的应用程序来处理。
应用程序直接渲染,无需向Wayland请求。只需在绘制完成之后向Compositor 发送一条信息表明这块区域被更新了。
Compositor收到这条信息后,立即重新合成整个桌面而无需向Wayland请求。
目前,Wayland使用OpenGL ES而不是传统的OpenGL。“从长远来看,我们需要完整的OpenGL支持,但问题是 libGL 会带来X的依赖性......”另一方面,使用OpenGL ES会使得Wayland更容易支持移动设备。 Wayland 目前并不支持网络透明性,但未来可能会支持。
PS:
Canonical 创始人马克·沙特尔沃思于 2010 年 11 月 4 日宣布 Wayland 将作为 Ubuntu 未来某一未定版本 Unity 接口的显示服务器。但是,2013年3月份,Canonical 确认他们将开发一个新的显示服务 Mir 而不是使用 Wayland 来替代X。
X Window System
X窗口系统(X Window System,也常称为X11或X)是一种以位图方式显示的软件窗口系统。最初是1984年麻省理工学院的研究,之后变成UNIX、类UNIX、以及OpenVMS等操作系统所一致适用的标准化软件工具包及显示架构的运作协定。X窗口系统通过软件工具及架构协定来创建操作系统所用的图形用户界面,此后则逐渐扩展适用到各形各色的其他操作系统上。现在几乎所有的操作系统都能支持与使用X。更重要的是,今日知名的桌面环境——GNOME和KDE也都是以X窗口系统为基础建构成的。
由于X只是工具包及架构规范,本身并无实际参与运作的实体,所以必须有人依据此标准进行开发撰写。如此才有真正可用、可运行的实体,始可称为实现体。目前依据X的规范架构所开发撰写成的实现体中,以X.Org最为普遍且最受欢迎。X.Org所用的协定版本,X11,是在1987年9月所发布。而今最新的参考实现(参考性、示范性的实现体)版本则是X11 Release 7.6(简称:X11R7.6),而此专案由X.Org基金会所领导,且是以MIT授权和相似的授权许可的自由软件。
X的历史比新生的Wayland和Mir要久远的多,关于X可以写的东西很多,在此就不赘述。想要了解更多关于X的更详细信息请前往维基百科:https://zh.wikipedia.org/wiki/X_Window%E7%B3%BB%E7%B5%B1