初识Wayland(X、Mir)

何涵畅
2023-12-01

【声明】下图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)。
————————————————
版权声明:本文为CSDN博主「evoo」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/iEearth/article/details/72790086

 类似资料: