2026 年能放心用 Wayland 了吗？

尽管 Wayland 作为 X11 的继任者发展迅速，但在特定高端硬件和专业工作流下仍未达到可用的标准。一次从 X11/i3 到 Wayland/Sway 的迁移尝试揭示了多重障碍：在作者的 8K 显示器和 NVIDIA 显卡环境下，硬件兼容性（如 MST 和 TILE 支持）依然不足；Sway 桌面虽与 i3 配置兼容，却存在鼠标延迟、键盘快捷键重复触发和 Xwayland 应用缩放不佳等问题；核心应用如 Chrome 和 Emacs 在 Wayland 下表现糟糕，前者硬件加速不稳定，后者则有明显的输入延迟和渲染差异。因此，结论是目前 Wayland/Sway 的体验相比成熟的 X11/i3 仍是降级，只有在解决了这些关键问题后，全面迁移才具有现实意义。

硬件兼容性是首要障碍

即便 NVIDIA 驱动近年来对 Wayland 的支持有所改善，但在特定配置下，硬件问题依然是迁移的主要阻碍。

8K 显示器支持不完善： 作者使用的 Dell 8K 显示器需要通过两条 DisplayPort 连接，并依赖 多流传输（MST） 和 TILE 属性来合并成单个屏幕。
- 虽然 GNOME 能正确识别分辨率，但存在严重的画面撕裂。
- Sway (wlroots) 则直接将它识别为两个独立的显示器，导致无法正常使用。
驱动与协议的协同问题： 经过深入调试，发现问题根源在于 NVIDIA 驱动未能正确处理 DRM（Direct Rendering Manager）的一个属性。虽然作者通过一个临时补丁解决了问题，但这表明 Wayland 生态在应对复杂硬件组合时仍显脆弱。

在GNOME下，虽然 tiled displays 得到了支持，但各个 tile 的更新并不同步，导致屏幕中央出现严重的撕裂，比我在X11下见过的任何情况都糟糕。

从 i3 到 Sway：桌面体验的倒退

Sway 被设计为 i3 的 Wayland 替代品，并兼容大部分 i3 配置。然而，在实际使用中，一系列新的问题浮现出来，使得日常操作体验下降。

鼠标延迟： 鼠标指针的移动感觉迟钝且不流畅，可能是因为 NVIDIA 驱动下的硬件光标支持尚未正常工作。
Xwayland 缩放问题： 无法为通过 Xwayland 运行的旧版应用提供良好的缩放支持，导致这些应用要么 模糊不清，要么被过度缩放。这使得向后兼容性形同虚设。
键盘输入异常： 偶尔出现键盘快捷键被执行两次的“幽灵按键”问题。例如，移动一个窗口时，可能会有两个窗口被一同移动。
功能缺失： Sway 未实现 i3 的布局保存与恢复功能，这破坏了作者依赖该功能自动排布工作区的习惯。

核心应用表现不佳

在日常工作最依赖的浏览器和文本编辑器上，Wayland 环境暴露出最令人难以接受的问题。

Chrome 浏览器：
- 硬件加速不稳定： GPU 进程频繁崩溃，导致 WebGL 等功能失效，浏览器体验远不如 X11 流畅。
- 窗口恢复失效： Chrome 无法在启动时将窗口恢复到它们关闭前所在的虚拟工作区。对于重度依赖多工作区和多窗口的用户来说，这极大地破坏了工作流。
Emacs 文本编辑器：
- 原生 Wayland 支持的代价： 标准版 Emacs 在 Wayland 下通过 Xwayland 运行，由于缩放问题而变得模糊。而使用原生支持 Wayland 的 pgtk 版本，则会遇到两个新问题：
  1. 显著的输入延迟，使得打字响应变慢。
  2. 文本渲染效果（如行高和字间距）与 X11 版本不同，且无法轻易调整回原来的样式。
屏幕共享：
- 流程繁琐：需要通过系统级的窗口选择器多次确认，而非在浏览器内直观选择。
- 质量问题：共享的窗口分辨率低，导致观看方看到的文本模糊不清。

结论：尚未准备好成为日常主力

尽管 Wayland 在技术上取得了长足进步，并且在许多标准配置上已能提供不错的体验，但对于有特定硬件和工作流需求的用户而言，它目前还不是一个可靠的选项。

从我的角度来看，从这个现有且对我来说完美运行的堆栈切换到 Sway 只会带来坏处。我观察到了以前没有的新图形故障。我花费最多时间的程序（Chrome 和 Emacs）运行得明显更差。

在以下关键问题得到解决之前，迁移到 Wayland/Sway 并不现实：

Sway 不再触发“幽灵按键”。
在 Sway 中切换窗口或工作区时不再出现视觉故障。
Chrome 的硬件加速能够持续稳定工作。
Chrome 窗口在启动时能恢复到之前的工作区。
Emacs 的问题得到解决： 要么 Xwayland 应用能正确缩放，要么原生 pgtk 版本修复输入延迟和渲染差异。