WayLand的架构和协议
WayLand的架构和协议
1. Wayland简介
1.1 Wayland定义和基本概念
Wayland 是一种显示服务器协议,它主要用于在操作系统中处理图形显示相关的事务。简单来说,它就像是一个 “交通警察”,指挥着图形应用程序和显示硬件之间的 “交通”,确保图形界面能够正确地呈现在屏幕上。 与传统的 X11 协议不同,Wayland 采用了更现代化的设计理念。它的协议更加简洁高效,能够更好地适应现代图形硬件和软件的需求。例如,在 Wayland 的架构中,窗口管理和合成等功能的实现方式与 X11 有很大区别。 重要性的体现性能方面高效的图形渲染:Wayland 能够更有效地利用现代图形处理单元(GPU)的功能。在处理复杂的图形场景,如高分辨率游戏、3D 建模软件等应用时,它可以通过减少不必要的中间环节,实现更快速的图形渲染。相比之下,X11 由于其复杂的架构和历史遗留问题,在图形渲染效率上可能会受到一定的限制。例如,在 X11 协议下,图形数据可能需要经过多个层次的转换和处理才能最终显示在屏幕上,而 Wayland 简化了这个过程,直接将应用程序的图形请求发送到 GPU 进行处理。 减少资源消耗:其简洁的协议使得系统资源的消耗得到降低。在多任务环境下,当运行多个图形应用程序时,Wayland 能够通过优化内存使用和 CPU 占用等方式,提高系统的整体性能。例如,对于一些轻量级的图形工具或者移动设备上的图形应用,Wayland 可以让它们在有限的资源下运行得更加流畅。 安全方面增强的权限管理:Wayland 采用了更严格的权限管理机制。在传统的 X11 系统中,存在一些安全隐患,比如一个恶意的应用程序可能会通过 X11 协议截获其他应用程序的输入或者图形输出信息。而 Wayland 通过限制应用程序的访问权限,使得这种安全风险大大降低。例如,每个应用程序在 Wayland 中都有明确的权限范围,只能访问和操作自己的窗口区域和相关资源,无法随意窥探其他应用程序的内容。 更好的隐私保护:对于用户的隐私信息,Wayland 提供了更好的保护。在一些涉及用户敏感信息的图形应用场景,如银行应用、密码管理器等,Wayland 可以防止这些信息被其他恶意程序窃取。这是因为它在设计上就注重了对图形数据的安全传输和访问控制。 对未来发展的适应性支持新的硬件技术:随着硬件技术的不断发展,如高分辨率显示器(4K、8K 甚至更高)、可变刷新率显示器、折叠屏设备等的出现,Wayland 的设计能够更好地适应这些新技术。它可以灵活地调整图形显示方式,以提供最佳的用户体验。例如,对于高刷新率显示器,Wayland 可以更好地协调应用程序和显示器之间的刷新率同步,避免画面撕裂等问题。 与新兴软件技术的融合:在软件技术方面,容器化技术(如 Docker)和云桌面技术等正在兴起。Wayland 的架构使得它更容易与这些新兴技术相结合。例如,在云桌面环境中,Wayland 可以通过优化协议传输,实现更高效的远程图形显示,为用户提供流畅的云端图形应用体验。
1.2 Wayland的发展
Wayland是由 Red Hat 开发者 Kristian Høgsberg 在 2008 年发起的。其发展历史如下: 诞生背景 随着硬件技术的飞速发展,特别是高分辨率显示器、触摸屏和图形处理器(GPU)性能的提升,X11 的一些固有缺陷逐渐暴露出来,如在处理高分辨率显示和流畅的动画效果时存在性能瓶颈,同时现代应用对图形显示的即时性和安全性有了更高的要求,Wayland 应运而生,旨在解决这些新的技术挑战1。 初期发展 自 2008 年提出以来,Wayland 一直备受关注,但在早期面临着一些问题,如作为一个全新的协议,它并不完全兼容 X11 的功能,给开发者和用户带来了迁移成本;其实现细节依赖于各种工具和协议,如 weston、kwin 和 mutter,这些工具的成熟度和稳定性在早期并不理想。 逐渐成熟 从 2010 年左右开始,Linux 桌面图形逐渐开始向将 Linux 内核及其组件放在中心的方向发展,Wayland 的优势逐渐显现。越来越多的 Linux 发行版开始支持 Wayland,并且一些新的桌面环境,如 GNOME 3.38 及以上版本,默认采用 Wayland 作为图形显示后端1。 现状与未来 目前,Wayland 的应用生态还在不断发展中,已经有许多应用程序开始适配 Wayland。随着硬件技术的不断进步,Wayland 有望充分利用新的硬件特性,如更强大的 GPU 和新型显示技术,为用户提供更加出色的图形显示体验。预计在未来几年内,更多的 Linux 发行版将默认采用 Wayland,使其成为 Linux 图形显示的主流技术。
1.3 Wayland的愿景
简单来说,Wayland想让你的电脑图形体验变得更棒!它通过简化图形渲染流程,直接与硬件对话,减少不必要的通信层,从而提高了性能和安全性。对于开发者而言,这意味着更少的代码维护工作;对于用户来说,则意味着更流畅的操作体验。
2. Wayland架构
2.1 X和Wayland:两者架构有何不同?
这个过程大致如下:
内核依旧负责捕捉输入事件并通过evdev接口发送给合成器。这部分与X的情况相似,所以我们可以继续利用内核中已有的输入驱动。
合成器则会根据它的场景图(scenegraph)来确定哪个窗口应该接收事件。由于合成器掌控着所有窗口的状态及其可能应用的各种变换,它可以准确地选择正确的窗口,并将屏幕坐标转换为窗口本地坐标。只要合成器能够计算出针对输入事件的逆变换,那么理论上可以对窗口施加任何类型的变换。
客户端接收到事件后,就像之前一样更新用户界面。不过,在Wayland下,渲染是在客户端这边完成的,之后只需告诉合成器哪些区域被更新了即可。
合成器收集来自各个客户端的损坏请求,然后重新组合屏幕内容。这个时候,合成器可以直接调用ioctl命令通过KMS安排页面翻转,无需再经过X Server这一环。
这样做的好处是减少了不必要的通信开销,提高了系统的响应速度和效率。Wayland的设计使得每个组件都能专注于自己最擅长的事情,从而构建出了一个更加流畅且安全的图形环境。
wayland的过程如下:
2.2 Wayland 的图像渲染
客户端渲染机制
硬件支持的重要性
客户端实现
服务器端实现
3. Wayland协议
WayLand协议, 是WayLand客户端与WayLand合成器之间的通讯协议
官方提供的WayLand协议的参考实现
https://gitlab.freedesktop.org/wayland/wayland
官方提供的WayLand合成器的参考实现
https://gitlab.freedesktop.org/wayland/weston
3.1 协议传输与消息格式
Wayland 协议通过UNIX域流套接字进行传输,通常情况下,该套接字的端点名为wayland-0(尽管可以通过环境变量WAYLAND_DISPLAY来更改)。从Wayland 1.15版本开始,实现可以选配支持位于文件系统任意位置的服务器套接字端点,只需将WAYLAND_DISPLAY设置为服务器端点监听的绝对路径即可。
每条消息被构造成由多个32位字组成的序列;值以主机的字节序表示。消息头部包含两个32位字:
第一个字是发送者的对象ID(32位)。
第二个字分为两部分:高16位是消息大小(以字节为单位),从头部开始计算(即最小值为8字节);低16位是请求或事件的操作码。
有效载荷描述了请求或事件的参数。每个参数总是对齐到32位边界;如果需要填充,填充字节的值未定义。没有前缀描述类型,而是隐式地从XML规范推断出来。
以下是参数类型的表示方式:
int, uint
表示32位有符号或无符号整数值。
fixed
有符号的24.8定点数。它是一种提供符号位、23位整数精度和8位小数精度的有符号十进制类型。在C API中,它作为一个不透明的结构体,并提供了转换为双精度浮点数和整数的帮助函数。
string
以一个无符号的32位长度(包括空终止符)开头,接着是字符串内容,包含终止的空字节,然后是对齐到32位边界的填充。空值用长度为0表示。
object
32位对象ID。空值用ID为0表示。
new_id
32位对象ID。一般情况下,新对象使用的接口可以从XML推断出来,但在接口未指定的情况下,new_id之前会有一个指定接口名称的字符串,以及一个指定版本的无符号整数。
array
以32位数组大小(以字节为单位)开头,接着是数组内容的直接拷贝,最后是对齐到32位边界的填充。
fd
文件描述符并不存储在消息缓冲区中,而是在UNIX域套接字消息的辅助数据(msg_control)中。
Wayland协议并未明确规定辅助数据在流中的确切位置,只规定文件描述符的顺序与消息及其内部的fd参数在网络上的顺序相同。
这意味着流中的任何字节,甚至是消息头部,都可能携带带有文件描述符的辅助数据。
客户端和合成器(compositor)应当排队等待接收的数据,直到他们有完整的消息可供处理,因为文件描述符可能会早于或晚于对应的数据字节到达。
3.2 核心接口概述
Wayland协议设计了一套核心接口,用于客户端与服务器之间的交互。这些接口提供了请求、事件和错误(实际上也是特殊类型的事件)的功能,如前文所述。虽然具体的合成器(compositor)实现可能会提供作为扩展的自有接口,但有一些接口是预期一定会存在的。
以下是Wayland的核心接口:
wl_display
作为核心全局对象,它充当了客户端与Wayland服务器之间通信的起点。通过这个接口,客户端可以获取其他全局对象,并发送或接收消息。
wl_registry
全局注册表对象,用来枚举当前可用的全局对象。客户端使用此接口来发现并绑定到它们需要的服务。
wl_callback
回调对象通常用于异步操作的完成通知,比如帧同步。
wl_compositor
合成器(compositor)单例,提供创建surface和其他图形资源的方法。
wl_shm_pool 和 wl_shm
这两个接口共同支持共享内存池的创建和管理,使得图像数据可以直接在客户端和合成器(compositor)之间交换。
wl_buffer
表示一个surface的内容,可以由多种不同方式创建,包括但不限于共享内存。
wl_data_offer, wl_data_source, wl_data_device 和 wl_data_device_manager
这组接口支持数据传输功能,例如剪贴板和拖放操作。
wl_shell 和 wl_shell_surface
提供了创建桌面风格surface的方法,并为这些surface提供了额外的元数据接口。
wl_surface
屏幕上的surface,是所有可视内容的基础元素。
wl_seat
输入设备的集合,每个seat代表一组输入设备,比如键盘、鼠标和触控屏。
wl_pointer, wl_keyboard, wl_touch
分别对应指针、键盘和触摸屏等输入设备的具体接口。
wl_output
描述合成器(compositor)输出区域的信息,比如显示器的几何属性和模式。
wl_region
定义了一个不规则形状的区域,可以应用于surface以控制其可见性或其他特性。
wl_subcompositor 和 wl_subsurface
支持子surface组合,允许将一个surface嵌入到另一个surface中,形成复杂的用户界面布局。
上述接口构成了Wayland协议的基本构建块,确保了客户端应用程序能够与合成器(compositor)进行高效且安全的通信。
4. Wayland对X11应用的支持
为了让那些还没迁移到Wayland上的老应用继续工作,Wayland引入了一个叫做XWayland的小帮手。它实际上就是一个小型的X Server,可以在Wayland环境中运行,接受来自传统X11客户端的连接请求,并将它们适配到新的显示协议之上。这样一来,用户就可以在同一桌面上同时运行两种类型的应用程序,无缝切换毫无压力。
尽管Wayland本身并不需要传统的X窗口管理器,但在某些情况下(例如通过XWayland运行X11应用时),它们仍然扮演着重要角色。此时,Wayland合成器会充当“超级管理员”,负责协调不同类型的窗口行为,确保整个系统稳定运行。
4.1 X11 应用程序的连接方式
X11应用程序连接到Xwayland的方式就如同它连接到任何其他X服务器一样。Xwayland负责处理所有的X11请求,并且在另一端,它作为一个Wayland客户端连接到了Wayland合成器(compositor)。
4.2 X Window Manager (XWM) 和 Wayland Window Manager (WWM)
XWM是Wayland合成器(compositor)不可或缺的一部分。它使用标准的X11窗口管理协议来管理所有通过Xwayland运行的X11窗口。重要的是,XWM充当了Xwayland窗口状态和Wayland合成器(compositor)的WWM之间的桥梁。这样,WWM就可以统一管理所有类型的窗口,无论是原生的Wayland窗口还是X11(即Xwayland)窗口。这对于提供一致的用户体验至关重要。
4.3 Xwayland的工作原理
由于Xwayland依赖Wayland进行输入和输出操作,所以它不需要像Xorg那样使用设备驱动程序。这意味着不会使用任何xf86-video-*或xf86-input-*模块。此外,Xwayland服务器没有配置文件。对于可选的硬件加速渲染,Xwayland采用了GLAMOR库。
4.4 单一实例的Xwayland
通常,一个Wayland合成器(compositor)只会产生一个Xwayland实例。这是因为许多X11应用程序假设它们可以通过X服务器与其他X11应用程序通信,而这需要共享同一个X服务器实例。这也意味着,除非Wayland合成器(compositor)特别选择通过为特定应用程序生成独立的Xwayland实例来打破这种通信,否则Xwayland不会保护或隔离各个X11客户端。值得注意的是,X11客户端与Wayland客户端之间是天然隔离的。
4.5 Xwayland的兼容性挑战
尽管Xwayland尽可能地兼容传统的X服务器,但要达到100%的兼容几乎是不可能的。特别是桌面环境组件中的X11窗口管理器基本上不受支持。一个X11窗口管理器无法识别原生的Wayland窗口,因此它只能管理X11窗口。然而,必须有一个XWM来保留独占的窗口管理角色,以便Wayland合成器(compositor)可以适当地显示X11窗口。对于其他的桌面环境组件,如分页器和面板,为了在WWM中通过XWM支持它们而添加必要的接口往往被认为是不值得的。
4.6 窗口标识与同步通信
在Xwayland中,一个X11窗口可能会对应于Wayland中的一个wl_surface对象。这个wl_surface对象用于输入和输出:它被输入事件引用,并用于向Wayland合成器(compositor)提供X11窗口的内容。X11窗口和wl_surface存在于不同的协议流中,因此需要将它们匹配起来以使XWM能够正常工作。
当Xwayland在Wayland上创建一个wl_surface时,它也会发送一个类型为原子"WL_SURFACE_ID"的X11 ClientMessage给对应的X11窗口,该消息的第一个32位数据元素携带的是wl_surface的Wayland对象ID。这是XWM关联wl_surface与X11窗口的方法。需要注意的是,创建wl_surface的请求和ID消息可能以任意顺序到达Wayland合成器(compositor)。因此,在实现XWM时,需要格外小心以避免(随机)死锁。强烈建议所有来自XWM的X11通信都应该是异步的,因为证明同步或阻塞的X11调用不会导致死锁通常是极其困难的。所有Wayland通信已经天生就是异步设计的。
5. 总结
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
2022-01-13 C#中Task.Delay() 和 Thread.Sleep() 区别
2022-01-13 理解C#中的 async await
2022-01-13 C#中ConfigureAwait的理解(作者Stephen)
2016-01-13 WPF调用office2010的ppt出错
2016-01-13 NSIS学习记录の----win8.1和win10对于NSIS创建的卸载快捷方式无法在开始目录下显示