原来 Linux 桌面才是最封闭的系统.

刚被 Wayland 折磨过的人来说。。 真的是 SB 。。。 为了所谓的安全。。？？ 就降低的电动车的标准吗？？

就现在各种应用在 Wayland 上功能缺失、Electron/Chromium 这种活跃的开源项目的输入法支持都才做好没多久来看，很难说 Wayland 真的在为开发者着想，虽然它确实某种程度上解决了 X11 的一些问题

不是封闭，而是没有规范

同意 24 楼的观点。你可以实现，PR 一个。 开放 = 碎片化 = 烂尾多 = 佛系 or 自力更生。

@cyp0633 至少安全了 XD

我感觉大多数人可能并不了解一个桌面系统是要有多复杂，所以会产生误解。之前我写过一篇介绍 wayland 合成器的，等有空我完整写一下关于桌面的。

简单回答一下这个帖子里提到的一些问题。我不是为了评价它是好是坏，只是尽量补充些信息。


- 全局热键

底层逻辑是非焦点应用不能获得键盘输入。所以 wayland 核心协议（ foundation ）没有，实际 org.freedesktop.portal.GlobalShortcuts 是属于 XDG Desktop Portal 的一部分，之前是 flatpak 沙盒环境的实现。或者再底层一点，wayland 只涉及二进制高性能 IPC ，其他的都走 dbus 。目前 KWin/Mutter 都支持了，hyprland/sway 虽然不直接支持，但对于用户来说反倒更简单，只是对应用来说缺少注册机制。

- 应用获知自己的位置，XY 坐标系

底层逻辑是窗口位于哪里是用户和合成器的事情，而不是应用程序的事情。安全考量是防止 UI 欺骗和覆盖攻击。这个问题协议层面无解，但作为合成器来说以私有协议方式实现这个功能不难，至于为什么不做可以去问开发者。

- 远程键鼠

X11 的方式是无限制的事件注入。Wayland 认为这种无鉴权无溯源的方式不安全。目前有两个解决思路，一个是走 XDG Portal 通过 libei(emulated input) 完成，另一个是 uinput 创建虚拟设备。这个只能说是软件更新没跟上，至少我用的 wayvnc 和 gnome rdp 都很正常。

- 类 macOS 统一权限/碎片化

历史原因不存在这个基础，实际上现在 systemd/dbus/wayland 这三个支柱，80% 代码都是 RH 出钱雇人做的，最大公约数就这水平了。不同于现实世界的标准之争，资本或者组织先确定标准，再去搞实现。Wayland 的现状是反正总有人不满意，纸面上的协议没什么意义，一堆私有协议最后卷剩下的那个才是真正的标准。

- 输入法

这个提过很多次了，fcitx5 实现了所有可以支持的协议，主要合成器也都支持至少一种协议，剩下就是软件自己的问题了。问题是输入法这协议都是老外最早设计的，他们根本不懂，所以只能我辈努努力改变现状了。



PS

我知道很多人有 RPA 或者自动化的需求，如果是开发者，在合成器基础上手搓“私有协议”不是很难的事情，如果是普通用户，基于 sway IPC 可以达到几乎任意想要的效果。如果是楼主这种开发应用发现没有办法适配我能理解，如果只是单纯抱怨那就没意思了。

@kuanat #46 感谢科普, 本意也是想给 Linux 添砖加瓦, 在完成 win 和 mac 适配的情况下尽量也照顾一下 linux 的用户, 没办法适配也就没办法了, 以后再说吧.

wayland 这种出来 N 年了连基本问题都解决不了，确实太拉，要安全可以，用户首先得能用才行啊，为了安全直接用不了，还是上不了桌， 目前 kde x11 用着，wayland 先等等吧

wayland 做的安全也是完全伪命题，因为大部分协议跑 dbus 上，但 dbus 的安全性基本纸糊的——你的 keychain 一旦解锁，实际上任何 app 都能读取其他 app 的 secret ，那个验证完全防君子不防小人
dbus 本身也一大堆问题，实现宽松，不强制约束序列化格式——你发个不良输入可以随意崩服务端,官方还十分鼓励厂商特定的扩展，而且那些扩展还几乎都没啥文档，不说扩展，本身 dbus 的标准也混乱无章文档和没有一样，导致实际实施标准的人也瞎写，你真按标准去读反而各种缺失字段
之所以 wayland 的 portal 搞得一地鸡毛，就是 dbus 本身的坑，各家实现看似相似，实际完全不一样，没有一个统一能用的实现
x11 之所以看上去比 wayland 好，是因为起码很多基础功能不依赖于 dbus 实现，现在 wayland 不做基础功能了，全依赖 dbus ，底裤就暴露出来了

@codehz

dbus 就拉鸡 太多应用依赖了 还越来越多应用强制依赖 dbus

@kuanat 这些所谓的安全性考量完全不合理，安全性（包括所谓的 UI 欺骗和覆盖攻击、键盘记录器等等）根本不应该从 Wayland 这样的显示协议的层面实现，而应该通过不同虚拟机之间的隔离实现，Qubes OS 的设计明显更合理：运行着多个不同的虚拟机，通过显示协议把它们合成在同一张桌面上，不同窗口可能来自不同的虚拟机并有着不可去除的彩色边框，它们之间通过虚拟机来实现隔离，从而提供安全性，而 Wayland 那样的安全性完全形同虚设，如果真有一个恶意程序正在运行它根本不能保证安全

@charles0 #51

我觉得“wayland 显示协议层面实现安全性”和“wayland 因为安全性拒绝了（应用获知窗口位置功能）实现”是有差别的。wayland 从来没有保证过什么。

就我个人的理解 wayland 协议就是一个特化的二进制 ipc ，它拒绝大多数非必须的功能提案进入核心（ foundation ），安全性是这个设计框架的副作用。

实现了 wayland 协议的合成器，一样可以实现 wayland 标准之外的功能，比如让应用获得自身位置，或者让非焦点应用获得全局键盘输入，让它变得更像 xorg ，让它变得不安全。这些功能写成提案就变成了所谓的扩展协议，如果 wayland 不认可，那就变成了私有协议。

我想表达的意思是，wayland 的设计好坏不能单纯以纸面上的协议 specs 来评价，也不能单纯以各种合成器已实现的部分做评价。

Wayland 的发展是有过重大转型的，原本的设想是 kdbus （也就是 dbus 的内核实现）为基础，但后来内核拒绝了 kdbus ，导致 Wayland 不得不依赖 systemd/dbus/pipewire/portal 一系列机制打补丁。现在 wayland 的样子很大原因是为了落地而做的妥协。

现在 linux 的现实就是，上面提到的这些底层机制，几乎绝大部分都是红帽员工写的，没得选。既然没得选，评价好或者不好就不那么有意义了。或许有人会说 xorg 也是一个选择，现实情况是没人想维护了，很难说用爱发电的 x11libre 能走多远。

@james122333 这有啥办法，其他 ipc 工具没第三方支持你自己搞等于没用
wayland 自己的那几个 protocol 根本不够用，官方全在搞真空中的球形鸡

@kuanat 现在的问题是一方面没得选，只有 X11 和 Wayland ，各有各的问题，另一方面又选择太多，只靠 Wayland 官方标准还不行，还要重复地、碎片化地去实现那几个 Wayland 不肯提供的东西，只会造成生态的分裂