目录1、The Wayland Protocol2、x11、wayland工作流程1x112waylandThe Wayland Protocol —新手入门学习二1、The Wayland ProtocolWayland是什么呢它是X Window还是要取代X WindowLinux桌面/移动会因此有什么变化在本篇中我将回顾历史通过简易的文字来先回顾一下X Window从而继续解答Wayland——古老的X Window和现代的桌面技术。X Window在1984年由MIT研发它的设计哲学之一是提供机制而非策略。举个最简单的例子吧X Window提供了生成窗口Window的方法但它没规定窗口要怎么呈现map或摆放这个策略是由外部程序—窗口管理器Window Manager所决定的。另外一个XWindow的主要特点便是Server/Client网络模型。不论是本地、远程的应用程序都统一通过Server/client模型来运作比如让远程的应用程序跑在本地上。X Window在推出之后快速演化在1987年时候其核心协议已经是第11版本了简称x11。这个版本已经将“提供机制而非策略”这个哲学贯彻地非常彻底以致于核心协议基本稳定不需要特别大的改动。于是乎20年后X Window依然是x11。你可能会诧异20年了X Window的核心都没有特别大的变化它能适应现代桌面的快速发展吗这就要再次提到XWindow的设计优势了X Window在核心层之外提供一个扩展层开发者可以开发相应扩展来实现自己的扩展协议比方说标准的Window都是矩形的我如何用它来画一个圆形的窗口X Window协议并未提供但是通过“shape”这个扩展XWindow可以实现不规则的窗体。所以啊这20年X Window除了继续完善核心协议、驱动以外很大程度上都是扩展使它保持“与时俱进”比如说1、要多头显示支持这个是由“Xinerama”扩展实现的2、要有多媒体视频回放的支持这个是由“X Video”扩展实现的3、OpenGL的3D支持则是通过“GL”扩展来实现的4、Compiz那样的合成桌面特效是怎么弄的它便是“Composite”5、甚至Keyboard的支持都是通过“xKeyboard Extension”也就是“XKB”的X Window的核心基本上就是在处理Server/Client、驱动之类的而外部的那些支持基本上全是通过“扩展”进行的。这没什么不好X Window的结构设计精良尽管是扩展但它们没有任何效能上的问题。通过扩展方便地实现了一些对新技术、新事物的支持而且方便维护这再好不过了。所以你看到了尽管20年过去了基于X Window的GNOME、KDE还能保持与同期Windows、Mac OS X 竞争甚至某些方面更好。你就不得不佩服这些前辈在最初设计时定下的设计哲学是多么正确了。虽然扩展的众多没有给X Window造成什么问题也跟XWindow的设计哲学相符但是其Server/Client的网络构架却一直倍受质疑。这便是X Window的效率问题X Window的Server/Client结构严重影响效率导致Linux桌面的效应速度一直不如WindowS、Mac OSX。让我们还是透过原理来解释。2、x11、wayland工作流程1x11这张便是当前X Window系统的架构图稍微解释一下X Client图形应用程序如Firefox、Pidgin等X Server你看不见的控制中心Compositor合成桌面系统如CompizKernel/KMS/evdevα这便是LinuxKernel后面会提到KMS技术了其中还有一项evdev是管理输入设备的。想像一下当你点击了浏览器xClient的“刷新”按钮将会发生以下事情1、你用鼠标点击了浏览器的“刷新”按钮这时内核收到了鼠标发来的事件并将其通过evdev输入。驱动发送至了XServer。这时内核实际上做了很多事情包括将不同品牌的鼠标发出的不同信号转换成了标准的“evdev”输入信息。2、这时XServer可以判断哪个Window该收到这个消息并将某座标按下按钮的消息发往浏览器xClient但事实上xServer并不知道它得到的窗口信息是不是正确因为现在是“Composite”即合成桌面的时代合成桌面的一个特点便是Compositor如Compiz管理窗口的一切×Server只能知道屏幕的某个坐标点收到了鼠标消息却不知道这个点下面到底有没有窗口。3、假设应用场景没这么复杂浏览器xCilent顺利地收到了消息这时浏览器xCilent要决定该如何做按钮要有按下的效果。于是浏览器xCilent再发送请求给×Server说“麻烦画一下按钮按下的效果。4、当xServer收到消息后它就准备开始做具体的绘图工作了首先它告诉显卡驱动要画怎么样一个效果然后它也计算了被改变的那块区域同时告诉Compiz那块区域需要重新合成一下。5、Compiz收到消息后它将从缓冲里取得显卡染出的图形并重新合成至整个屏幕一当然Compiz的“合成”动作也属于“渲染”也是需要请求xServer我要画这块然后XServer回复你可以画了。xClient-XServer再从XServer-Compositor尽管Compiz已经掌管了全部最终桌面呈现的效果但xServer在收到Compiz的“渲染”请求时还会做一些“本职工作”如窗口的重叠判断、被覆盖窗口的剪载计算等等不然它怎么知道鼠标按下的坐标下是Firefox的窗口呢一这些都是无意义的重复工作而且Compiz不会理会这些Compiz依然会在自己的全屏幕“画布”上画着自己的动画效果……从这个过程基本可以得出结论X Client- X Server-Compositor这三者请求染的过程不是很高效2wayland还记得前文中点击浏览器xCilent的刷新按钮这个应用场景吧在Wayland里所有的流程是这样的1、内核收到了鼠标发出的信息经过处理后转发到了Wayland Compositor就像之前发往X Server一样。2、Compositor收到消息后立马能知道哪个窗口该收到这个消息因为它就是总控制中心它掌握窗口的层级关系、动画效果因此它知道该坐标产生的鼠标点击信息应该发送给谁就这样Compositor将鼠标的点击信息发送给了浏览器xCilent。3、浏览器xCilent的收到了消息这时如果是在X Window下的话Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里浏览器xCilent可以自行进行绘制而不需要再请求Compositor的许可这就是传说中的直接渲染机制Direct RenderWayland不管Client的绘制工作整个过程变得十分简单而且高效当浏览器xCilent自行完成了按钮状态的绘制后它只需要通知Compositor某块区域已经被更新了。4、Compositor收到浏览器xCilent发来的信息的再重新合成那块更新的那块区域将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。从这个过程基本可以得出结论1、Wayland的直接渲染架构彻底结束了传统X Window在渲染图形时需要不停的向Server请求、确认再绘制这个繁琐的过程理论上响应速度有了爆发式增长2、Wayland从根本上消除了ServerCompositor的重复劳动仅有且只需要有一个Compositor合成器而已。Compostior就是Wayland上的X Server但是它更纯粹它不像X Server一样像个大家长什么都要管。Compositor只做该做的事情把上面的过程简化成任务便是1、基于Wayland协议处理evdev的信息2、通知Client即应用程序对相关事件做出反应至于应用程序想怎么反应Compositor不需要过问3、收到Client的状态更新重新合成图形或管理新的图形布局。讲了这么多技术大家肯定枯燥了究竟现在有没有可以跑的Wayland Compositor呢当然现在只要你从官方取得源码然后根据教程进行编译就能跑起一个简单实现的Wayland Compositor。由于Wayland协议的灵活性Wayland Compositor也可以拥有自己的后端比如直接在DRM上跑Wayland不需要X或者在X Window上跑起一个Wayland Compositor相当于在X Window上用Xephyr再跑一个X Window。当前我在UOS1050的图形环境下就跑起了默认的这个简易的Wayland几点说明支持透明、阴影和简单的窗口管理所有的图形绘制都是通过Cairo-glCairo的OpenGL后端进行简单的说它就是一个去除X Window中不必要的设计、充分利用现代Linux内核图形技术的一个显示机制它的出现是自然而然的它的使命不是为了消灭X Window而是将Linux的图形技术发挥至更高的一个境界。传统的X Window即经典X应用、Gtk 1.x/2.x等旧应用也会在相当长一段时间内得到继续支持通过Wayland Client的形式跑在Wayland Compositor上直到最终升级、取代或被淘汰。