Can I finally start using Wayland in 2026?

2026-01-04

2026年，我终于可以开始使用 Wayland 了吗？

Wayland 是 Linux 上用于实现图形栈的 X server（X11、Xorg）的继任者。Wayland 项目实际上始于 2008 年，比我在 2009 年创建面向 X11 的 i3 平铺窗口管理器早一年——但在过去的 18 年里（！），Wayland 在我的电脑上始终无法使用。我不想被困在已被弃用的软件上，因此每年都会尝试开始使用 Wayland，本文将概述在 2026 年阻碍我迁移到 Wayland 的原因。

历史背景

在最初的几年里，Wayland 在我的机器上甚至很少能启动。偶尔运气好能显示出点东西时，我也只能在演示 compositor(合成器) Weston 中启动一些玩具般的演示应用。

大约在 2014 年，GNOME 开始支持 Wayland。几年后 KDE 也跟进了。主流应用（如 Firefox、Chrome 或 Emacs）适配 Wayland 的速度则慢得多，直到最近才不需要用户通过自定义标志或环境变量来启用实验性实现——在某些情况下，比如 geeqie，至今仍是如此。

不幸的是，多年来驱动支持状况一直很差。使用 nVidia 显卡时——它是唯一支持我的 8K 显示器的显卡——Wayland 要么完全无法工作，要么会出现严重的图形故障和崩溃。

进入 2020 年代，越来越多的发行版宣布计划默认切换到 Wayland，甚至放弃其 X11 会话，而 RHEL 也正在逐步减少对 X server 的贡献。

像 Asahi Linux（面向 Mac，拥有自己的 GPU 驱动！）这样的现代 Linux 发行版显然已将 Wayland 视为其主要的桌面栈，而对 X11 仅提供尽力而为的支持。

因此，切换到 Wayland 的压力越来越大！它现在准备好了吗？还缺少什么？

让 Wayland 启动起来

硬件

我使用实验室电脑进行测试，它是我 2022 年的高端 Linux 电脑稍作升级的版本。

我在stapelberg 的常用配置：我的 2020 年桌面布置一文中更详细地描述了我的配置。

对本文而言最重要的是，我使用一台Dell 8K 32 英寸显示器（分辨率：7680x4320！），根据我的经验，它仅与 nVidia 显卡兼容（我有时也会尝试其他显卡）。

因此，我的实验室电脑和主力电脑都配备了 nVidia GPU：

实验室电脑配备 nVidia GeForce RTX 4070 Ti。
主力电脑配备 nVidia GeForce RTX 3060 Ti。

（如果你好奇我为什么在主力电脑上用较旧的显卡：有一次我遇到了崩溃，怀疑是 GPU 的问题，所以又从 4070 换回了旧的 3060。）

nVidia 驱动支持

多年来，nVidia 驱动在 Wayland 下完全不受支持。

据说，nVidia 拒绝支持 Wayland 当时使用的 API，坚称自家的 EGLStreams 方案更优。幸运的是，从 nVidia 495 驱动（2021 年底）开始，他们加入了对 GBM(通用缓冲管理器)（Generic Buffer Manager）的支持。

但是，即便有了 GBM 支持，虽然现在可以启动许多 Wayland 会话，会话运行却并不流畅：你会看到严重的图形故障和伪影，根本无法正常工作。

解决这些故障的关键是 explicit sync(显式同步) 支持：由于 nVidia 驱动不支持 implicit sync(隐式同步)（而 AMD 或 Intel 支持），Wayland（以及 wlroots 和 sway）需要获得显式同步支持。

Sway 1.11（2025 年 6 月）和 wlroots 0.19.0 是首批支持显式同步的版本。

仍未解决：8K 显示器的 TILE 支持

虽然 nVidia 驱动现在本身已经能在 Wayland 下工作，但在我的配置中仍不足以使用 Wayland：我的Dell UP3218K 显示器需要两条 DisplayPort 1.4 连接，并依赖 MST(多流传输)（Multi Stream Transport）和 TILE 支持。这种组合在 X11 下过去 8 年多一直运行良好。

虽然 GNOME 能够以 7680x4320@60 的原生分辨率成功配置该显示器，但在 sway 中它却被错误地显示为两台独立的显示器。

出现这一行为的原因是wlroots 不支持 TILE 属性（2019 年的 issue #1580）。幸运的是，在 2023 年，贡献者 EBADBEEF 提交了草案合并请求 !4154，为 TILE 属性添加了支持。

但是，即便打上了 TILE 补丁，我的显示器仍无法正常工作：显示器的右半部分始终是黑的。使用 grim 截图时却能看到完整画面，因此这似乎是一个输出问题。从 2025 年 8 月开始，我就此与 EBADBEEF 有过几次交流（感谢查看！），但我们没能找出问题所在。

一个季度后，我在使用编程助手Claude Code（撰写本文时为 Opus 4.5）调试复杂问题方面积累了不错的经验，于是决定再试一次。在两天时间里，我运行了多项测试来缩小问题范围，让 Claude 分析源代码（包括 sway、wlroots、Xorg、mesa 等）并生成可手动运行的测试程序。

最终，我得到了一个与 Wayland 无关的最小复现程序，它展示了 SRC_X DRM 属性在 nVidia 上不起作用（但例如在 Intel 上却能正常工作！）：我在 nVidia 论坛上发布了附带视频的错误报告，希望能有 nVidia 工程师来查看！

关键在于，在定位到错误后，我让 Claude 实现了一个变通方案：将屏幕右半部分（位于 SRC_X=3840）复制到另一个缓冲区，然后以 SRC_X=0 显示该缓冲区。

打上该补丁后，我第一次能够在 8K 显示器上使用 Sway 了！🥳

顺便一提，我说 GNOME 能够成功配置原生分辨率，并不意味着该显示器在 GNOME 下可用！虽然 GNOME 支持平铺显示，但各个图块的更新并不同步，因此你会在屏幕中间看到严重的撕裂，比我在 X11 下见过的任何情况都要糟糕。GNOME/mutter 的合并请求 !4822有望解决这一问题。

软件：NixOS

在 2025 年期间，我将所有电脑都切换到了 NixOS。它的声明式方法非常适合进行此类测试，因为你可以可靠地将系统恢复到早期版本。

为了在我的 NixOS 25.11 安装上提供 Wayland/sway 会话，我在 NixOS 配置文件（configuration.nix）中添加了以下几行：

# GDM display manager (can launch both X11/i3 and Wayland/Sway sessions)
services.displayManager.gdm.enable = true;
services.displayManager.gdm.autoSuspend = false;

# enable GNOME (for testing)
services.desktopManager.gnome.enable = true;

programs.sway = {
  enable = true;
  wrapperFeatures.gtk = true;
  extraOptions = [ "--unsupported-gpu" ];
};

我还在 environment.systemPackages 中添加了以下 Wayland 专用程序：

environment.systemPackages = with pkgs; [
  # …
  foot          # terminal emulator
  wtype         # replacement for xdotool type
  fuzzel        # fuzzy matching program starter
  wayland-utils # for wayland-info(1)
  gammastep     # redshift replacement
];

请注意，激活此配置会终止你正在运行的 X11 会话（如果有的话）。

为确保万无一失，我在更改配置后重启了整台机器。

实验结果

使用这套配置，我在 Wayland 会话中度过了大约一整个工作日。尝试真正完成一些工作会暴露出在随意测试中可能不会显现的问题。这一天的大部分时间都花在了尝试修复 Wayland 问题上😅。以下各节将说明我的发现/观察。

桌面：i3 → sway

很多年前，当 Wayland 变得更流行时，有人在 i3 的 issue 跟踪器上询问是否会将 i3 移植到 Wayland。我说不会：我怎么可能把一个程序移植到在我任何一台电脑上都无法运行的环境中？而且，我也知道，由于全职工作，我没有时间成为早期采用者并参与塑造 Wayland 的发展。

这种态度导致 Drew DeVault（德鲁·德沃特）大约在 2016 年启动了Sway 项目，旨在打造 i3 的 Wayland 版本。我并不把 Sway 视为竞争对手。相反，我觉得人们如此喜欢 i3 项目，以至于愿意费心为其他环境创建类似的程序，这非常了不起！这是多么美好的赞美！😊

Sway 的目标是与 i3 配置文件兼容，而且基本上也做到了。

如果你好奇，以下是我基于 Sway 默认配置所做的修改，主要是为我使用的NEO 键盘布局调整按键绑定，以及配置以前在我的 ~/.xsession 文件中配置的 input/output 块：

我对默认 Sway 配置的修改

--- /home/michael/src/sway/config.in	2025-09-24 19:08:38.876573260 +0200
+++ /home/michael/.config/sway/config	2025-12-31 15:50:38.616697542 +0100
@@ -9,19 +9,76 @@
 # Logo key. Use Mod1 for Alt.
 set $mod Mod4
 # Home row direction keys, like vim
-set $left h
-set $down j
-set $up k
-set $right l
+set $left n
+set $down r
+set $up t
+set $right d
 # Your preferred terminal emulator
 set $term foot
 # Your preferred application launcher
-set $menu wmenu-run
+set $menu fuzzel
+
+font pango:Bitstream Vera Sans Mono 8
+
+titlebar_padding 4 2
+
+# Make Xwayland windows recognizeable:
+for_window [shell="xwayland"] title_format "%title [Xwayland]"
+
+workspace_layout stacking
+
+# Open two terminal windows side-by-side on new workspaces:
+# https://github.com/stapelberg/workspace-populate-for-i3
+exec ~/go/bin/workspace-populate-for-i3
+
+exec gammastep -l 47.31:8.50 -b 0.9
+
+input * {
+   xkb_layout "de"
+   xkb_variant "neo"
	repeat_delay 250
	repeat_rate 30
+}
+
+input * {
+	accel_profile adaptive
+	pointer_accel 0.2
+}
 
 ### Output configuration
 #
-# Default wallpaper (more resolutions are available in @datadir@/backgrounds/sway/)
-output * bg @datadir@/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill
+output * bg /dev/null fill #333333
+output * scale 3
 #
 # Example configuration:
 #
@@ -33,14 +90,41 @@
 #
 # Example configuration:
 #
-# exec swayidle -w \
-#          timeout 300 'swaylock -f -c 000000' \
-#          timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' \
-#          before-sleep 'swaylock -f -c 000000'
+exec swayidle -w \
+         before-sleep '~/swaylock.sh' \
+         lock '~/swaylock.sh'
 #
 # This will lock your screen after 300 seconds of inactivity, then turn off
 # your displays after another 300 seconds, and turn your screens back on when
 # resumed. It will also lock your screen before your computer goes to sleep.
+bindsym $mod+l exec loginctl lock-session
+
+  # Notifications
+  bindsym $mod+period exec dunstctl close
 
 ### Input configuration
 #
@@ -63,11 +147,13 @@
     # Start a terminal
     bindsym $mod+Return exec $term
 
     # Kill focused window
-    bindsym $mod+Shift+q kill
+    bindsym $mod+Shift+x kill
 
     # Start your launcher
-    bindsym $mod+d exec $menu
+    bindsym $mod+a exec $menu
 
     # Drag floating windows by holding down $mod and left mouse button.
     # Resize them with right mouse button + $mod.
@@ -142,12 +228,11 @@
     bindsym $mod+v splitv
 
     # Switch the current container between different layout styles
-    bindsym $mod+s layout stacking
+    bindsym $mod+i layout stacking
     bindsym $mod+w layout tabbed
-    bindsym $mod+e layout toggle split
 
     # Make the current focus fullscreen
-    bindsym $mod+f fullscreen
+    bindsym $mod+e fullscreen
 
     # Toggle the current focus between tiling and floating mode
     bindsym $mod+Shift+space floating toggle
@@ -156,7 +241,7 @@
     bindsym $mod+space focus mode_toggle
 
     # Move focus to the parent container
-    bindsym $mod+a focus parent
+    bindsym $mod+u focus parent
 #
 # Scratchpad:
 #
@@ -192,37 +277,25 @@
     bindsym Return mode "default"
     bindsym Escape mode "default"
 }
-bindsym $mod+r mode "resize"
+#bindsym $mod+r mode "resize"
 
 #
 # Status Bar:
 #
 # Read `man 5 sway-bar` for more information about this section.
 bar {
-    position top
 
     # When the status_command prints a new line to stdout, swaybar updates.
     # The default just shows the current date and time.
-    status_command while date +'%Y-%m-%d %X'; do sleep 1; done
+    status_command i3status
 }

我在使用 Sway 时遇到了以下问题：

我不知道该如何配置与之前相同的 libinput 设置。请查看xinput-list-props-mx-ergo.txt了解我在 X11 上的配置。Sway 可用的 accel_profile 设置似乎与我之前使用的不匹配。
鼠标光标/指针似乎有些卡顿？！当我移动轨迹球时，光标反应似乎变慢了，而且在屏幕上移动的也不够流畅。
Simon Ser（西蒙·塞尔）推测，这可能是因为目前 nVidia 驱动的硬件光标支持无法正常工作。
没有 Xwayland 缩放：通过 Xwayland 启动的程序会模糊（默认情况下）或双重缩放（当设置 Xft.dpi: 288 时）。这是 Sway 特有的限制：KDE 在 2022 年就已修复此问题。从Sway issue #2966 来看，Sway 开发者似乎出于某种原因不喜欢这种做法，但这对我的迁移来说非常遗憾：通过 Xwayland 运行旧程序的向后兼容选项对我来说实际上是不可用的。
有时，键盘快捷键似乎会被执行两次！比如，当我聚焦堆叠中五个 Chrome 窗口的第一个并将其移动到另一个工作区时，两个窗口会被移动，而不是一个。我还会看到类似这样的消息（虽然与双重快捷键问题并不完全相关）：
```
[ERROR] [wlr] [libinput] event0  - https: kinT (kint36): client bug: event processing lagging behind by 32ms, your system is too slow
```
……而这在我看来是不对的。我的高端 Linux 电脑无论如何都不算慢。

GTK：字体大小

当我第一次启动 GIMP 或 Emacs 等 GTK 程序时，我注意到所有字体都太大了！显然，我仍有一些与缩放相关的设置需要像这样重置：

gsettings reset org.gnome.desktop.interface scaling-factor
gsettings reset org.gnome.desktop.interface text-scaling-factor

调试提示：使用 dconf dump / 显示 GNOME 设置（存储在 ~/.config/dconf 中）。

GTK：后端

像 geeqie 这样的程序显然需要显式设置 export GDK_BACKEND=wayland 环境变量，否则它们会在 Xwayland 中运行。很奇怪。

字体渲染

我还注意到 X11 和 Wayland 之间的字体渲染有所不同！例如，在 Chrome 浏览器标签标题和地址栏中就能看到差异：

起初我以为 Wayland 可能默认使用了不同的字体抗锯齿和字体微调设置，但我尝试了以下设置（默认值为 font-antialiasing=grayscale 和 font-hinting=slight），却无法让渲染效果恢复到以前的样子：

gsettings set org.gnome.desktop.interface font-antialiasing 'rgba'
gsettings set org.gnome.desktop.interface font-hinting 'full'

更新：感谢 Hugo（雨果）指出，在 Wayland 下，GTK3 会忽略 ~/.config/gtk-3.0/settings.ini 配置文件，而只使用 dconf！设置以下 dconf 设置后，字体渲染就一致了：

gsettings set org.gnome.desktop.interface font-name 'Cantarell 11'

锁屏：swaylock

i3lock 显而易见的替代品是 swaylock。

我很快就发现这两个程序在架构上存在差异：

i3lock 会显示一个锁屏窗口。当你终止 i3lock 时，屏幕就会解锁。
当你终止 swaylock 时，你会陷入红屏死机。
要摆脱这种状态，你需要重启 swaylock 并解锁。你可以通过向 swaylock 进程发送 SIGUSR1 从命令行解锁。

这让我非常惊讶，但却是（Wayland）设计使然！详情请参阅Sway issue #7046，以及这段来自 ext-session-lock-v1 Wayland 协议的引文：

“合成器必须停止渲染并停止向普通客户端提供输入。相反，合成器必须用不透明颜色清空所有输出，使其正常内容被完全隐藏。”

好吧，所以当你通过 SSH 启动 swaylock 进行测试时，请记得一定要解锁，而不是仅仅用 Ctrl+C 取消 swaylock。并祈祷它永远不会崩溃。

我过去通过一个包装脚本来启动 i3lock，该脚本会关闭显示器（有输入时唤醒）：

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

revert() {
    xset dpms 0 0 0
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM
xset +dpms dpms 15 15 15
(sleep 1 && xset dpms force off) &
pactl set-sink-mute @DEFAULT_SINK@ 1
i3lock --raw 3840x2160:rgb --image ~/i3lock-wallpaper-3840x2160.rgb -n 
revert

在 Wayland 下，DPMS 行为必须以不同的方式实现，使用 swayidle：

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

swayidle -w \
  timeout 5 'swaymsg "output * dpms off"' \
  resume 'swaymsg "output * dpms on"' &
swayidle=$!

revert() {
    kill $swayidle
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM

pactl set-sink-mute @DEFAULT_SINK@ 1
swaylock --image ~/i3lock-wallpaper-3840x2160.jpg
revert

i3 IPC 自动化

i3 窗口管理器可以通过其IPC 接口（进程间通信）进行扩展。

我使用了一些利用此接口的小工具。

在使用这些工具与 Sway 配合时，我注意到以下问题：

使用 go.i3wm.org/i3/v4 Go 包的工具目前需要特殊的套接字路径钩子。我们或许应该在包中加入透明处理以简化过渡。
通过 Sway 配置中的 exec 启动的工具在你退出 Sway（swaymsg exit）并登录到新会话后，竟会意外地继续运行！
我的workspace-populate-for-i3 无法工作：
- Sway 没有实现 i3 的布局保存/恢复，因为德鲁·德沃特在 2017 年决定该功能“过于复杂和取巧，收益却太小”。太可惜了。我有一些喜欢的布局，需要用其他方式来复现。
- Sway 不支持用 [con_id] 条件匹配工作区节点。有一个拉取请求 #8980（五天前独立提交）来修复这个问题。
我的wsmgr-for-i3 部分可用：
- 恢复工作区（wsmgr restore）可用。
- Sway 的rename workspace 命令实现似乎没有从目标名称中识别工作区编号。

终端：foot

在 X11 上，我使用 rxvt-unicode（URxvt）终端模拟器。除了速度快、外观简洁之外，它还有一些我不想失去的易用性功能：

在回滚缓冲区（= 命令输出）中向后搜索
使用键盘快捷键打开回滚缓冲区中的 URL
在相同工作目录中打开新的终端窗口
从 shell 更新终端标题

在早期的实验中，我尝试过 Alacritty 或 Kitty，但都不满意。

多亏了anarcat 的博文“Wayland：从 i3 到 Sway 的迁移”，我发现了 foot 终端模拟器，它看起来是一个非常不错的选择！

我开始编写一个foot.ini 配置文件来匹配我的 URxvt 配置，但后来我注意到至少有些颜色似乎不匹配（一些带有绿色/红色背景的文本行看起来不同）。我不确定原因，还没有进一步研究。

我在使用 foot 时注意到以下问题：

按下 Ctrl+Enter（我似乎经常会误按）会导致出现转义序列，而 URxvt 则只是将 Ctrl+Enter 当作 Enter 处理。
这可以在你的 shell（对我来说是 Zsh）中通过变通方法解决，详情请参阅 foot issue #628。
用鼠标双击 URL 的一部分会选中该 URL（如预期），但却不包含 https: 方案前缀！当你确实想用鼠标操作时会很烦人。
我可以按住 Ctrl 来变通，这会让 foot 选中光标下直到下一个空格字符之间的所有内容。
在 foot 中启动 screen(1) 会导致在 screen 会话中运行的程序没有颜色支持。可能是与 terminfo 相关的问题……？我在使用 GNOME 终端时也能复现此问题。但在使用 URxvt 或 xterm 时则正常。
选中文本时，会高亮行内的文本，但不会高亮整行。这与我习惯的其他终端模拟器不同，但我没看到可以更改的选项。
这是一张截图，显示在“kthreadd”右侧三击后的 foot：
但对 echo 输出的一行进行三击时，仅高亮内容，而不是整行：

文本编辑器：Emacs

我觉得 Emacs 对 Wayland 的支持相当令人失望。标准版的 Emacs 仅支持 X11，因此在 Sway 上，它会以 Xwayland 方式启动。由于 Sway 不支持 Xwayland 的缩放，Emacs 会显示模糊（顶部/背景窗口）：

原生 Wayland 支持（底部/前景窗口）仅在 pgtk 版本的 Emacs 中提供（在 NixOS 上为 emacs-pgtk）。pgtk 曾是一个独立分支，但在 Emacs 29（2023 年 7 月）中已被合并。在 X11 上似乎存在 pgtk 的问题（在 X11 上启动 Emacs-pgtk 时会收到警告），因此目前不得不提供两个独立版本……

不幸的是，pgtk 的文本渲染看起来与原生 X11 文本渲染不同！行高和字母间距似乎有所不同：

我不明白为什么会不同！有谁知道如何让它与之前的效果保持一致吗？

除了文本渲染不同之外，对我来说另一个主要问题是输入延迟：Emacs-pgtk 感觉明显比 Emacs 慢（响应更迟钝）。这在 Reddit 上被多次报告（帖子 1、帖子 2）以及 Emacs bug #71591，但似乎没有任何解决方案。

我还需要一个远程运行 Emacs 的解决方案。到目前为止，我通过 SSH 使用 X11 转发（在光纤连接上效果不错且延迟低）。我应该去看看 waypipe，但还没有机会。

浏览器：Chrome

启动 Chrome 并查看 chrome://gpu 调试页面时，看起来一切正常：

但很快，在移动和调整浏览器窗口大小后，GPU 进程就会崩溃，并出现如下消息，例如 WebGL 不再是硬件加速：

ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Scanout|Rendering|Texturing
ERROR:ui/gfx/linux/gbm_wrapper.cc:405] Failed to create BO with modifiers: Invalid argument (22)
ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Texturing
ERROR:gpu/command_buffer/service/shared_image/shared_image_factory.cc:981] CreateSharedImage: could not create backing.
ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:397] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
ERROR:components/viz/service/gl/exit_code.cc:13] Restarting GPU process due to unrecoverable error. Context was lost.
R:gpu/ipc/client/command_buffer_proxy_impl.cc:321] GPU state invalid after WaitForGetOffsetInRange.
ERROR:content/browser/gpu/gpu_process_host.cc:1005] GPU process exited unexpectedly: exit_code=8704

当然，在没有硬件加速的情况下使用浏览器是非常令人沮丧的，尤其是在高分辨率下。使用 --disable-gpu-compositing 启动 Chrome 似乎可以避免 GPU 进程退出，但 Chrome 仍然感觉不如在 X11 上流畅。

对我来说另一个大问题是，Sway 不会在我关闭 Chrome 窗口时所在的工作区上重新打开 Chrome 窗口。对 _NET_WM_DESKTOP EWMH 原子的跟踪和恢复支持已在 2016 年 1 月加入到 i3，并在 2016 年 5 月加入到 Chrome，在 2020 年 3 月加入到 Firefox。

在任何时候我通常都有 5 个以上的工作区，甚至更多的 Chrome 窗口，因此每天（当我启动工作电脑时）都要在 10 多个 Chrome 窗口中进行整理是非常烦人的。

西蒙·塞尔表示，这将通过一个新的 Wayland 协议（xdg-session-management，合并请求 !18）来解决。

屏幕共享

我经常远程工作，因此屏幕共享对我来说是一项必备功能。我几乎每天都会在浏览器中使用屏幕共享，涉及不同的场景和不同的需求。

在 X11 上，我习惯了 Chrome 的以下体验。我点击“Window”标签页并看到窗口预览。当我选择窗口并确认后，其内容就会被共享：

要在 Wayland/sway 上实现屏幕共享，你需要安装 xdg-desktop-portal 和 xdg-desktop-portal-wlr（后者专用于 sway 所使用的 wlroots）。

安装好这些包后，我看到的行为如下：

我可以共享 Chrome 标签页。
我可以共享整个显示器。
我无法共享特定窗口（整个显示器会显示为单个窗口）。

这是 xdg-desktop-portal-wlr（及其他）的限制，应该会在即将发布的 Sway 1.12 版本中得到解决。

我将 NixOS 配置改为从 git 使用 sway 和 wlroots 来尝试该功能。当我点击“Window”标签页时，我会看到一个选择器，需要在其中选择一个窗口：

选择窗口后，我在 Chrome 中仅能看到该窗口内容的预览：

确认后，我会再次看到一个选择器，需要再次选择窗口。值得注意的是，在这第二步中，预览的窗口与选择的窗口之间没有任何关联——如果我选择了不同的窗口，共享的就是那个窗口：

现在该窗口已被屏幕共享（所以该功能现在可用了；不错！），但不幸的是分辨率很低，意味着我的同事看到的文本是模糊的。

我将此报告为 xdg-desktop-portal-wlr issue #364，问题似乎在于应用了错误的缩放因子。issue 中提供的补丁对我有效。

但是，从整体流程来看，整个过程似乎是错误的：当我点击 Chrome 的“Window”标签页时，我不应该看到一个选择器。我应该看到所有窗口的预览。我应该能够在 Chrome 中选择窗口，而不是通过单独的选择器。

缩放故障

我还注意到一个非常烦人的故障：当启用输出缩放时，（某些！）窗口的内容会在我在窗口（位于标签式或堆叠容器中）或工作区之间切换时“跳动”。

我最初在 foot 终端模拟器中注意到这一点，其行为如下：

通过切换工作区，或在堆叠或标签式容器中切换焦点，将焦点切换到另一个 foot 终端。
新的 foot 终端的文本内容显示时略有偏移。
几毫秒内，foot 的文本会跳回到正确位置。

我在内容移动几像素后，用 iPhone 捕捉到了这一帧，就在焦点切换到此窗口后不久：

后来，我还注意到 Chrome 窗口在切换后会短暂显示模糊。

我的猜测是，由于 Sway 会为不可见窗口将缩放因子设为 1，因此在切换焦点时，你会看到缩放因子为 1 的内容缓冲区，直到应用程序提供了缩放因子为 3 的内容缓冲区。

通知：dunst

dunst 原生支持 Wayland。我尝试了 dunst 1.13，没有注意到任何问题。

选择器：rofi

rofi 自 v2.0.0（2025-09-01）起可在 Wayland 上工作。

我将 rofi 与 rofimoji 一起用作表情符号选择器。对于文本输入，wtype 似乎可以替代 xdotool。我没有注意到任何问题。

截图：grim？

我尝试了 maim(1) 的替代品 grim(1)，但不幸的是 grim 的 -T 标志用于选择要捕获的窗口，使用起来相当繁琐（并且以 1 倍缩放捕获）。

有人能推荐一个好的替代品吗？

结论

终于，我在让 Wayland 会话在我的环境中工作方面取得了一些进展！

在给出这次 Wayland/sway 实验的结论之前，让我先说明一下我在 X11/i3 上的体验非常好。在日常使用电脑时，我没有看到任何撕裂或其他伪影或故障。我不使用合成器，因此我的输入延迟非常好：我曾在 X11 上的 Emacs 中使用我自制的键盘测量到大约 763 微秒（加上输出延迟），请参阅kinX：延迟测量（2018）。

因此从我的角度来看，从这个现有的、对我而言完美运行的栈（对我来说）切换到 Sway 只会带来缺点。我观察到以前没有的新图形故障。我花费最多时间的程序（Chrome 和 Emacs）运行明显更差。由于实现方式不同，或因为我需要完全更换程序，我遇到了大量新错误。

首次，一个可媲美的 Wayland 体验似乎已近在咫尺，但现实中仍需要数周甚至数月的工作。根据我的经验，调试会话很快就会花费数小时，因为我需要更换显卡并重新连接显示器来缩小错误范围。不幸的是，我没有时间对修复这些众多问题做出太多贡献，所以我暂时会继续使用 X11/i3。

对我来说，当以下条件满足时，Wayland/Sway 会话才能作为日常主力使用：

Sway 不再有时会触发某些按键绑定两次（“幽灵按键”）
在 Sway 中切换窗口或工作区时不再看到故障。
Chrome 持续保持硬件加速。
启动时 Chrome 窗口能恢复到之前的工作区。
Emacs 要么：
- 通过 Xwayland 运行且 Sway 能实现缩放，
- 要么其 pgtk 变体能修复输入延迟问题，并能以某种方式让文本渲染与之前保持一致。