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 在我的電腦上幾乎連啟動都有困難。就算幸運地有畫面出現，也只能在展示用的合成器 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。

（如果你好奇為何我在主力電腦上使用較舊的顯示卡：我曾遇到一次疑似顯示卡造成的當機，所以就從 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 下運作，但對我的配置來說仍不夠：在我的 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" ];
};

我也將以下 Wayland 專用的程式加入到 environment.systemPackages：

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 tracker 上詢問是否會將 i3 移植到 Wayland。我當時的回答是不會：我怎麼可能把程式移植到一個在我的任何電腦上都跑不起來的環境？而且，我也知道在全職工作的情況下，我沒有時間成為早期採用者並參與形塑 Wayland 的開發。

這種態度促使 Drew DeVault（德魯·德沃）在 2016 年左右發起了 Sway 專案，其目標是打造 Wayland 版的 i3。我並不將 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 可能預設使用了不同的字型反鋸齒與字型 hinting 設定，但我嘗試調整以下設定（預設為 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 套件的工具目前需要一個特殊的 socket 路徑處理。我們或許應該在套件中加入透明處理，以簡化過渡。
從 Sway 設定檔中以 exec 啟動的工具，在你離開 Sway（swaymsg exit）並登入新工作階段後，竟會意外地繼續執行！
我的 workspace-populate-for-i3 無法運作：
- Sway 並未實作 i3 的版面配置儲存／還原功能，因為 Drew 在 2017 年決定此功能「過於複雜且取巧，效益卻太小」。真可惜。我有一些喜歡的版面配置，得用其他方式重現了。
- Sway 不支援以 [con_id] 條件來匹配工作區節點。有一個 pull request #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 Terminal 時也能重現此問題。但在使用 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 視窗所在的工作區上重新開啟該視窗。對 _NET_WM_DESKTOP EWMH atom 的追蹤與還原支援，已在 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（後者是 wlroots 專用的，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？

我嘗試了 grim(1) 來取代我慣用的 maim(1)，但可惜 grim 的 -T 旗標用來選取要擷取的視窗時，使用起來相當不便（而且會以 1 倍縮放擷取）。

有人有推薦的好替代方案嗎？

結論

終於在讓 Wayland 工作階段於我的環境中運作方面取得了一些進展！

在給出這次 Wayland/sway 實驗的結論之前，讓我先說明我在 X11/i3 上的體驗其實非常好。我在日常使用電腦時，完全看不到任何畫面撕裂或其他殘影或異常。我沒有使用合成器，因此輸入延遲非常低：我曾測量到在 X11 上搭配自製鍵盤，於 Emacs 中的輸入延遲約為 763 μs（加上輸出延遲），請參閱 kinX：延遲測量（2018）。

所以從我的角度來看，從這個現有且（對我而言）完美運作的架構切換到 Sway，只有缺點。我觀察到新的圖形異常，而這在以前是沒有的。我花最多時間使用的程式（Chrome 和 Emacs）執行起來明顯變差。由於實作方式不同，或因為需要完全更換程式，我遇到了大量的新錯誤。

首次看來，與 X11 旗鼓相當的 Wayland 體驗似乎已近在咫尺，但實際上仍需要數週甚至數月的投入。以我的經驗，除錯過程很快就會耗費數小時，因為我需要更換顯示卡並重新接線螢幕來縮小錯誤範圍。不幸的是，我沒有時間為修復這些眾多問題做出太多貢獻，所以目前我仍會繼續使用 X11/i3。

對我而言，Wayland/Sway 工作階段要能成為日常主力，需要滿足以下條件：

Sway 不再有時會重複觸發某些按鍵綁定（「幽靈按鍵」）
在 Sway 中切換視窗或工作區時不再看到異常。
Chrome 能持續保持硬體加速。
Chrome 視窗在啟動時能還原到先前的工作區。
Emacs 要不是：
- 透過 Xwayland 執行且 Sway 能讓縮放正常運作。
- 或是其 pgtk 變體能修復輸入延遲問題，並能以某種方式讓文字渲染與以往一致。