Can I finally start using Wayland in 2026?

2026-01-04

2026 年，我終於可以開始用 Wayland 了嗎？

原文由 Michael Stapelberg 于 2026-01-04 發布，訂閱此部落格

Wayland 是 Linux 上負責實作圖形堆疊的 X 伺服器（X11、Xorg）的後繼者。Wayland 專案其實早在 2008 年就啟動了，比我在 2009 年打造 i3 平鋪式視窗管理器（X11 版）還早了一年——但在過去 18 年裡（！），Wayland 在我的電腦上從來就沒能正常使用過。我不想一直卡在已被棄用的軟體上，所以每年都會嘗試轉移到 Wayland，本文將整理 2026 年依然阻礙我完成遷移的原因。

歷史背景

最初的幾年，Wayland 在我的機器上幾乎連啟動都成問題。偶爾運氣好畫面真的有東西跑出來，也只能在示範用的合成器 Weston 裡執行一些玩具性質的示範程式。

2014 年左右，GNOME 開始支援 Wayland，KDE 也在幾年後跟進。Firefox、Chrome 或 Emacs 等主要應用程式支援 Wayland 的進度則慢得多，直到最近才脫離需要使用者透過額外參數或環境變數手動啟用實驗性實作的階段——某些程式甚至到今天仍是如此，例如 geeqie。

遺憾的是，驅動程式的支援狀況多年來一直很糟。以 nVidia 顯示卡來說——那是唯一能支援我那台 8K 螢幕的顯示卡——在 Wayland 下不是完全無法運作，就是會出現嚴重的畫面破圖與當機。

進入 2020 年代，越來越多發行版宣布打算預設改用 Wayland，甚至要移除 X11 工作階段，而 RHEL 也正在逐步減少對 X 伺服器的貢獻。

像 Asahi Linux（針對 Mac、還自帶 GPU 驅動程式！）這類現代 Linux 發行版，更是明確把 Wayland 視為主要的桌面堆疊，X11 僅以盡力而為的方式支援。

轉向 Wayland 的壓力因此越來越大！那麼，現在已經準備好了嗎？還缺什麼？

讓 Wayland 跑起來

硬體

這次測試用的是我的實驗室電腦，它是我 2022 年的高階 Linux PC稍微升級後的版本。

關於整體配置的細節，我在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 下運作，對我的環境來說仍然不夠：我的 Dell UP3218K 螢幕需要透過兩條 DisplayPort 1.4 連接線，搭配 MST（Multi Stream Transport，多串流傳輸）與 TILE 支援。這個組合在 X11 下過去 8 年多來都運作得非常正常。

雖然 GNOME 能成功以原生解析度 7680x4320@60 設定這台螢幕，但在 sway 中它卻會被錯誤地識別為兩台獨立的螢幕。

出現這種情況的原因是wlroots 不支援 TILE 屬性（2019 年的 issue #1580）。幸好，貢獻者 EBADBEEF 在 2023 年提交了草稿合併請求 !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 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 設定。關於我在 X11 上的設定，請見xinput-list-props-mx-ergo.txt。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 PC無論如何都不算慢。

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 時，卻會進入紅色死亡畫面（Red Screen Of Death）。
要脫離這個狀態，你必須重新啟動 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 路徑 hook。我們或許應該在套件中加入透明處理，以簡化過渡。
透過 Sway 設定檔以 exec 啟動的工具，在你離開 Sway（swaymsg exit）並登入新工作階段後，竟會意外地繼續執行！
我的workspace-populate-for-i3 無法運作：
- Sway 並未實作 i3 的版面配置儲存／還原功能，因為 Drew 在 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 月）中已合併。似乎 pgtk 在 X11 上有些問題（在 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 視窗，非常惱人。

Simon Ser 表示，這將透過新的 Wayland 協定（xdg-session-management，合併請求 !18）來解決。

螢幕分享

我經常遠端工作，因此螢幕分享對我來說是不可或缺的基本功能。我幾乎每天都會在瀏覽器中使用螢幕分享，場景與需求各不相同。

在 X11 下，我習慣 Chrome 有以下體驗。我點擊「Window」分頁，會看到各個視窗的預覽。當我選取視窗並確認後，該視窗的內容就會被分享：

要在 Wayland/sway 上讓螢幕分享運作，你需要安裝 xdg-desktop-portal 與 xdg-desktop-portal-wlr（後者是 wlroots 專用的，sway 即使用它）。

安裝好這些套件後，我看到的行為如下：

我可以分享 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 上運作。

我搭配rofimoji 將 rofi 作為表情符號選擇器。文字輸入方面，以 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 版本修復輸入延遲問題，並能設法讓文字渲染與以前一致。