【Wayland】初识Wayland（X、Mir）

【声明】下图copy自wikipedia，如有侵权请告知。

在介绍Wayland之前，先熟悉一下X与Mir，简单来说，同样作为显示服务，X是一个老派的庞然大物，Wayland是一颗节节高的芝麻，Mir是一个颇受争议的新秀，其它的显示服务还包括Android的SurfaceFlinger，MacOS家族的Quartz Compositor等。

1、Mir

【参考ubuntu-wiki】https://wiki.ubuntu.com/Mir
【参考wikipedia】https://en.wikipedia.org/wiki/Mir_(software)

Mir是一种计算机显示服务，用于Linux操作系统，由Canonical开发，2013年3月4日公开，计划替代Ubuntu上的X窗口系统，开发Unity 8，不过随着Ubuntu 18.04 LTS的发行，Canonical宣称Unity 8将不再支持GNOME，Mir与其竞争者Wayland各行其道，主要投资于IoT项目，其它应用还包括SDL、GTK+、Qt5等，另外，Mir争议颇多，如其License为GPLv3。在架构方面，Mir像Wayland一样，基于EGL，并且使用了一些始于Wayland的基础套件，如Mesa的EGL实现、Jolla的libhybris，以及兼容于X的基于XWayland的XMir，此外，Mir还有一些基础套件延用自Android，如input框架、Protocol Buffer等等。下图是Mir的基本组成及架构。

2、X

【参考x.org-wiki】https://www.x.org/wiki/
【参考wikipedia】https://en.wikipedia.org/wiki/X_Window_System

X即X11、X Window System，是用于在类UNIX的操作系统上的位图显示的窗口系统，提供了GUI环境的基本框架，可以在显示设备上绘制、移动窗口，通过鼠标、键盘、触摸屏与用户交互。X由X.Org Foundation维护，遵守MIT协议，当前参考实现为X.Org Server。在架构方面，X使用了C/S模型，客户端和服务器可以在同一个机器上，也可以在不同的机器上，X作为Server为应用程序这个Client提供显示和I/O服务，基本结构如下图所示。

上面提到的X.Org Server是X显示服务的一种开源实现，对应的客户端实现为Xlib或XCB，XCB旨在取代Xlib。

3、Wayland

【参考wayland】https://wayland.freedesktop.org/
【参考wikipedia】https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

Wayland是一个显示服务协议，服务端为Wayland Compositor，把X的X Server和Compositor合二为一，旨在替换X，作为类Unix操作系统上更现代、简介的窗口系统，遵守MIT协议，提供了Wayland Compositor的参考C语言实现Weston。下面是Wayland官网文档给出的架构简图，与上面的X架构简图对比，少了两个传输步骤。

近些年，Linux桌面图形渲染接口移植到了Linux内核组件，如DRI、DRM，目的是提供一个更加灵活、高性能的图形系统。Wayland由一个协议和参考实现Weston组成，GTK+和Qt使用了Wayland取代X，其它的许多应用程序也期望得到Wayland的支持。Wayland目前还不像X一样是网络透明的，将来将会支持这个特性，实现手段可能是像VNC一样的pixel-scraping，或者像RDP、SPICE、X一样发送一个rendering command stream，或者使用Wayland Server代理来发送压缩的图片给真正的Compositor。Wayland发起人解释了为什么不扩展X而是创建Wayland，X已非常臃肿，许多模块已都移植到了Linux内核，剩下的还有许多功能也都不常用。下面是使用了Wayland的一个图形系统简图。

Wayland协议为Client-Server模式，客户端为图形应用程序，请求屏幕上像素缓冲区的显示，服务器为Compositor，控制这些缓冲区的显示。Wayland参考实现Weston包括两层协议，一个为low-level或wire协议，基于消息，主要就是IPC，如Linux Domain Socket，这层协议为手动写的C语言实现；另一个是high-level协议，处理客户端和Compositor需要交换的消息，以实现窗口系统的基本功能，这层协议是基于对象的异步协议，包括全局对象和非全局对象，从规定格式的XML文件中自动生成，可以灵活地动态扩展或者用于错误验证。Wayland参考实现包括两部分，libwayland-client和libwayland-server，其架构简图如下所示。

Wayland协议在其源码protocol/wayland.xml中定义，下面列出了一部分。

除了Wayland的核心协议外，还有一些扩展协议，如管理Compositor中Surface的XDG-shell协议，车载娱乐系统IVI-shell协议。

Wayland协议不包括渲染API，而是使用DRM，这需要客户端在同Compositor共享的缓冲区中渲染窗口，在这种情况下，客户端有更多选择，如图形渲染库Cario和OpenGL，或者是支持Wayland的高级图形库GTK+和Qt，以及Freetype字体渲染引擎等等。渲染缓冲区结果存放在wl_buffer对象中，这个对象与具体的实现相关，但必须是客户端和Compositor共享的。如果客户端使用软描画（CPU），结果存储在系统内存中，客户端和Compositor可以使用共享内存传递缓冲区数据而不需要额外的拷贝工作，接口为wl_shm、wl_shm_pool，这种方法的缺陷是拷贝数据到GPU以进行显示，造成图形描画性能下降。所以，最常见的做法是使用硬件（GPU）加速API直接渲染到video memory，这些API如OpenGL、OpenGL ES、Vulkan，客户端和Compositor可以使用特殊的句柄共享这块GPU缓冲区，这样就避免了拷贝数据到GPU的耗时工作，而且Compositor还可以使用同一个API对屏幕上将显示的最终场景进行合成优化。渲染完成并且缓冲区共享之后，Wayland客户端通知Compositor显示缓冲区的渲染结果，这需要客户端绑定缓冲区，缓冲区存放了Surface对象的渲染结果，然后发送commit请求给这个Surface，把对相应缓冲区的有效操作传递给Compositor。下面是包括了渲染API的结构图。

Weston是Wayland显示服务的参考实现，只支持Linux，因为依赖于Linux内核的一些模块，如KMS、GBM、udev等，input处理依赖于evdev，buffer处理依赖于GBM，从上图中可以看出，还有一些其他实现，如Clayland等。

下面是Wayland与libinput的结构图。

现在，许多软、硬件都支持Wayland，Wayland的流程程度越来越广。

最后，Wayland与X的区别可参照https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)。