话说在上篇(揭开Wayland的面纱(一):X Window的前生今世)中我介绍了一些X Window的历史及发展,还没有提到Wayland本身,不少人已经等不及了。 在本篇正式开始介绍Wayland之前,让我们先回到2008年11月4日,也就是整整两年前,我当时在中文领域第一时间报道了"Wayland"的新闻:Wayland:Linux的新X Server,在其后的一个月 ,又写了:Wayland最新动态。 所以Wayland依然是贯彻"提供机制,而非策略"的Unix程序。 "什么?Wayland还是Server/Client模式?" 由于Wayland协议的灵活性,Wayland Compositor也可以拥有自己的后端:比如直接在DRM上跑Wayland(不需要X),或者在X Window上跑起一个Wayland Compositor
接着上一章内容编写 Wayland 客户端(一)。 客户端程序: $ weston & $ WAYLAND_DISPLAY=wayland-1 . 我们已经成功写出了第一个 Wayland 程序。 Wayland 的基本原理 Wayland 是一种 客户端-服务器协议。 避免往返延迟是 Wayland 设计的目标之一,因为往返延迟会严重拖慢通信。Wayland 的目标是保持极高的速度和效率。 因此,Wayland 是异步的。 最后,Wayland 定义了一些 具体的对象类型(接口) 及其可调用的方法,这被称为 Wayland 核心协议。
继续前面的章节: 编写 Wayland 客户端(一) 编写 Wayland 客户端(二) 黑方块 《黑方块》是卡济米尔·马列维奇(Kazimir Malevich)的著名画作: 在本节的最后,我们将构建一个至少同样酷 但在 Wayland 里,表面并不仅限于桌面窗口。 分配缓冲区(Allocating a buffer) Wayland 被设计成支持多种格式和不同来源的缓冲区。 xdg-shell.xml 生成: $ sudo apt install wayland-protocols $ wayland-scanner client-header \ /usr/share /wayland-protocols/stable/xdg-shell/xdg-shell.xml \ xdg-shell-client-protocol.h $ wayland-scanner private-code
像这类应用,就需要专门针对 Wayland 做适配。 在搜索 Wayland 开发资料,特别是 Wayland 客户端应用开发资料时,发现资料太少了。 但是要处理比较复杂的问题,比如 Wine 中的 Wayland 移植,不对 Wayland 有深入的理解,就很难去解决窗口显示、输入法等深层次问题。 这里以 Writing Wayland clients 这份教程为基础,通过翻译大部分章节,补充缺失的章节,根据最新 Wayland 协议添加一些实例,希望给大家呈现一个比较完整的 Wayland 客户端开发教程 你可以在维基百科的相关文章以及官方网站上阅读更多关于 Wayland 的内容。 我需要了解 Wayland 吗? 在开始编写 Wayland 客户端之前,你可能会想:我是否必须深入了解 Wayland 协议? 答案是:不一定。 你完全可以在不了解 Wayland 内部细节的情况下开始编写客户端程序。
Wine 项目组同样意识到 Wayland 的发展方向,已着手推进 Wayland 驱动的开发。然而,由于 Windows 窗口模型与 Wayland 的设计理念存在显著差异,移植工作面临不少挑战。 在多数发行版的 Wayland 会话中,Wine 仍主要依赖 XWayland,通过旧的 X11 驱动路径来运行。 在 Wayland 驱动仍不完善的阶段,调试工作尤为关键。 Weston:轻量级 Wayland 合成器的最佳选择 然而,要调试 Wine 的 Wayland 驱动,又必须在 Wayland 环境中运行,这便形成了矛盾。 我想起自己曾写过一篇介绍 Wayland 客户端开发的文章《编写 Wayland 客户端(二)》,其中提到 Weston——用于展示 Wayland 协议与功能的参考实现合成器。 编译 Wine 的 Wayland 支持 要编译 wayland 支持,需要额外安装如下开发包: libwayland-dev wayland-protocols libxkbcommon-dev linux-libc-dev
在 Linux 桌面领域,Wayland 常被提及为 “X11 的继任者”。 然而,与这一趋势形成鲜明对比的是:Wayland 相关的开发资料却异常稀少。 经过 XDG shell 的角色定义之后,Wayland 中才逐步具备了与 X11 类似的“窗口层级”概念,但这种层级是显式、受限且由 compositor 主导的,这正是 Wayland 与 X11 、状态和策略高度集中 Wayland 将绘制责任下放到客户端,只保留最小、清晰的合成与调度核心 X11 依赖隐式状态与扩展演进 Wayland 依赖显式协议与受控语义 从 X11 的角度理解 Wayland 只有在理解 Wayland 设计初衷的前提下,才能读懂 winewayland 中的实现是对 Wayland 架构原则的自然遵循。
本文将带你一起探索 Wine 项目在纯 Wayland 环境下的表现,看看它如今的 Wayland 支持究竟到了什么程度。 那 Wine 对 Wayland 的支持如何呢?目前 Wine 项目对 Wayland 支持标记为实验性支持,也就是说还不完善,但可以用。 如果说这么简单的窗口都还存在问题,那说明 Wine 对 Wayland 的支持还相当不完善。这显然并不是应用程序一方的问题。这涉及到 Wayland 的设计哲学。 目前 Wayland 仍在快速演化中,新的实验性协议层出不穷,旧的接口也在陆续稳定。或许,要等 Wayland 像 X System 一样迭代到“第 11 版”,Wayland 才能迎来真正的稳定。 因此,在现阶段,仍不建议在纯 Wayland 环境下运行 Wine 应用。对 Wayland 的探索值得期待,但现在,它更像是一场未完的实验。
Ubuntu"或其他地方看到了这篇文章:Ubuntu 决定未来将启用 Wayland X-Server。 Wayland是什么呢?它是X Window?还是要取代X Window?它的优势在哪里? 在本篇中,我将回顾历史,展望未来,通过简易的文字,来先回顾一下X Window,从而继续解答Wayland。 它便是下篇要介绍的:Wayland!!! 本文来源 https://imtx.me/archives/1573.html
年初写过一篇文章《从 X11 到 Wayland,迈出这一步为何如此艰难?》,分析了从 X11 演进到 Wayland 所面临的困难。直到今天,Wayland 替代 X11 仍不容乐观。 一、X11 的痛点与 Wayland 的诞生 先看一张 X11 和 Wayland 架构对比图,来自 freedesktop.org: 从上图可以看出,Wayland 相比 X11 架构,就是拿掉了 X /wayland。 wayland.dtd:DTD 代表 Document Type Definition(文档类型定义)。wayland.dtd 文件本身不定义任何 Wayland 的功能。 wayland.xml:这是 Wayland 的核心协议定义文件,遵循 wayland.dtd 定义的语法。它定义了任何 Wayland 系统都必须实现的最基本、最核心的接口和功能。
简单地说,Wayland是一套display server(Wayland compositor)与client间的通信协议,而Weston是Wayland compositor的参考实现。 这个协议分为Wayland核心协议和扩展协议(位于Weston中)。Weston作为Wayland compositor的参考实现,一般和Wayland同步发布。 编译时会首先编译出wayland-scanner这个可执行文件,它利用expat这个库来解析xml文件,将wayland.xml生成相应的wayland-protocol.c,wayland-client-protocol.h 与Wayland类似,protocol目录下放着Wayland协议定义。 wayland-egl库提供了Wayland中surface和EGL粘合的作用。
只是为了录制屏幕而 在 Xorg 和 Wayland 之间切换,这不是很方便。 这种情况下,我很高兴地得知,由于 Pipewire 的帮助,在 OBS Studio v27 中支持了 Wayland。 但即使是这样,也不是很简单,因此我将向你展示使用 OBS Studio 在 Wayland 上录制屏幕的步骤。 使用 OBS 在 Wayland 上进行屏幕录制 让我们来看看它是如何完成的。 第二步:检查 Wayland 捕获是否工作 请确认你正在使用 Wayland。现在启动 OBS Studio,查看它在第一次运行时显示的所有内容。我不打算展示这些。 如果你看到了,你现在就可以开始在 Wayland 中录制屏幕了。 第三步:让改变成为永久性的 这很好。你刚刚验证了你可以在 Wayland 上录制屏幕。 export QT_QPA_PLATFORM=wayland 退出并重新登录。现在 OBS 会自动开始使用这个参数,你可以用它来录制 Wayland 的屏幕。
简单地说,Wayland是一套display server(Wayland compositor)与client间的通信协议,而Weston是Wayland compositor的参考实现。 这个协议分为Wayland核心协议和扩展协议(位于Weston中)。Weston作为Wayland compositor的参考实现,一般和Wayland同步发布。 编译时会首先编译出wayland-scanner这个可执行文件,它利用expat这个库来解析xml文件,将wayland.xml生成相应的wayland-protocol.c,wayland-client-protocol.h 与Wayland类似,protocol目录下放着Wayland协议定义。 wayland-egl库提供了Wayland中surface和EGL粘合的作用。
, .pVulkanInit = WAYLAND_VulkanInit, .pOpenGLInit = WAYLAND_OpenGLInit, }; 所以,与 X11 驱动不同,Wayland return TRUE; } 可以看到,在 WAYLAND_WindowPosChanging 函数中,Wayland 驱动创建 wayland_win_data 结构。 而在 WAYLAND_WindowPosChanged 函数中,Wayland 驱动创建相应的 Wayland 表面(surface)。 Wine 的窗口在 Wayland 上通常不映射为真实“窗口”,而是 Wayland 的 surface。 它不在窗口创建时立即创建 Wayland 资源,而是在窗口真正需要显示时才创建相应的 Wayland 表面,这是一种更符合 Wayland 协议设计理念的延迟创建模式。
一、为什么是 Wayland? Wayland 作为 Linux 新一代显示服务器协议,正逐步取代已有 30 多年历史的 X11。 Fedora、Ubuntu、Arch 等主流发行版已将 Wayland 设为默认显示服务器 [[4]]。 JetBrains 此次在 2026.1 中默认启用 Wayland,正是对这一生态趋势的积极响应。 与 X11 相比,Wayland 的核心优势在于: 特性 X11 Wayland 架构 客户端-服务器模型,应用可直接操作其他窗口 合成器主导,应用仅能控制自身内容 安全性 低:应用可监听键盘事件、截屏其他窗口 Wayland 通过客户端-side 渲染 + 合成器合成的机制,彻底解决这一痛点: 2️⃣ 输入法全面支持,多语言开发无障碍 2024.2 预览版中,Wayland 模式曾因缺乏输入法(IM)支持而饱受诟病
所以这篇文章不打算长篇大论,而是通过编写一个简单的 Wayland 客户端程序,带大家实际体验一下 Wayland 的“坑”与门道。 我们要开发的 Wayland 客户端非常简单,只需在窗口中显示一句 “Hello wayland”。 其实,写图形界面程序一般推荐用 GTK、QT 这样的 GUI 框架,这样可以自动适配 X11、Wayland 等后端。但为了演示 Wayland 客户端的底层写法,这次我们选择“手搓”一个。 运行程序 保证你当前在Wayland桌面环境下,执行: ./hello-wayland-v1 程序会弹出一个窗口,显示“Hello Wayland”文字,10秒后自动关闭。 这种情况下,就需要 Wayland 客户端来绘制。 小结 本文通过手搓 Wayland 客户端的实践,带你从零体验了 Wayland 协议下窗口程序的开发流程。
一、为什么是Wayland?Linux桌面的必然演进Wayland作为Linux新一代显示服务器协议,正逐步取代已有30多年历史的X11(X.Org)。 Fedora、Ubuntu、Arch等主流发行版已将Wayland设为默认显示服务器[[4]]。JetBrains此次在2026.1EAP中默认启用Wayland,正是对这一生态趋势的积极响应。 与X11相比,Wayland的核心优势在于:特性X11Wayland架构客户端-服务器模型,应用可直接操作其他窗口合成器主导,应用仅能控制自身内容安全性低:应用可监听键盘事件、截屏其他窗口高:严格的权限隔离 Wayland通过客户端-side渲染+合成器合成的机制,彻底解决这一痛点:2️⃣输入法全面支持,多语言开发无障碍2024.2预览版中,Wayland模式曾因缺乏输入法(IM)支持而饱受诟病。 随着Wayland生态的成熟,我们有理由相信:Linux将成为开发者最高效、最愉悦的开发平台。
Wayland 多显示器屏幕捕获 新增支持 Wayland 环境下的多显示器屏幕捕获功能(演示),满足 Linux 桌面用户的多屏协作需求。 4. 修复了在 Arch/Wayland 环境下 CPU 占用率达到 100% 的问题。 2. 修复了 macOS 作为服务(已安装)运行时出现低帧率的情况。 3. 总结 RustDesk 1.4.3 在跨平台远程桌面体验上进行了重要升级,尤其针对 Wayland 环境支持、多平台 Bug 修复以及安全性优化,有助于提升稳定性和易用性。
https://www.bilibili.com/video/BV1iU49zYEYM?t=98.0
() 初始化进程名称 调用 wayland_process_init(),建立与 Wayland 合成器的连接并完成协议初始化 其中,真正承担 Wayland 环境搭建与协议协商的是 wayland_process_init Wayland 进程初始化(wayland_process_init) wayland_process_init 负责完成 Wine Wayland 驱动在进程级别的初始化,其主要步骤包括: 连接 Wayland , process_wayland.wl_event_queue); wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue process_wayland.pointer.wl_pointer) wayland_pointer_init(wl_seat_get_pointer(seat)); else process_wayland.keyboard.wl_keyboard) wayland_keyboard_init(wl_seat_get_keyboard(seat));
在《从 X11 到 Wayland,迈出这一步为何如此艰难?》一文中,我们分析过从 X11 过渡到 Wayland 所面临的诸多挑战。 随着数年改进,Wayland 支持日益成熟,Ubuntu 21.04 再次将 Wayland 会话设置为默认,但在检测到 NVIDIA 专有驱动时仍会自动退回 Xorg。 Ubuntu 只保留单一桌面会话路径,使 GNOME 可以集中精力发展 Wayland,而不再维护 Xorg 与 Wayland 的双路线。 XWayland 更像是在 Wayland 桌面里“外挂”一个小型 X server,而不是将 X11 的复杂性直接塞进 Wayland。 尽管如此,Wayland 替代 X11 是不可逆的趋势。Wayland 提供更现代的安全模型,对输入和窗口隔离更严格,有助于减少潜在安全漏洞。