我在 2026 年可以開始改用 Wayland 了嗎？ （★ 111 分）
Wayland 是 Linux 圖形顯示架構中用來取代 X server（X11/Xorg）的協定與生態系。作者 Michael Stapelberg 從 2008 年 Wayland 啟動以來幾乎每年都嘗試遷移，但長期被驅動與應用程式支援卡住；2026 年這次實測聚焦在他要用的「極端」桌面情境：nVidia 顯示卡加上 Dell 32 吋 8K 螢幕（7680x4320@60，需雙 DisplayPort 1.4、MST 與 `TILE` 拼接）。近年多個發行版與桌面環境逐步把 Wayland 當預設、甚至弱化 X11，也讓他更想確認「現在到底能不能日用」。
他指出 nVidia 在 2021 年驅動 495 才加入 GBM（Generic Buffer Manager）後，Wayland 才比較能啟動，但仍曾因同步機制不同而出現嚴重畫面瑕疵；直到 explicit sync（顯式同步）落地，Sway 1.11（2025/06）與 wlroots 0.19.0 才讓 nVidia 在 wlroots/Sway 上「基本可用」。然而真正的關卡是 8K 拼接顯示：wlroots 多年缺乏 `TILE` 屬性支援，補丁雖能讓螢幕以單一輸出顯示，卻在 nVidia 上出現右半邊黑屏。作者在 Claude Code（AI 程式助理）協助下做出最小重現程式，鎖定是 nVidia 對 DRM 的 `SRC_X` 屬性行為異常，並提出以額外 buffer 複製右半畫面迴避的修補，終於首次在 8K 螢幕上把 Sway 跑起來；同時也提到 GNOME 雖能正確拼接，但 tile 更新不同步導致撕裂更嚴重，需等 Mutter（GNOME 視窗管理器/合成器）後續修正。
進入「實際工作一整天」後，問題轉向日用體驗：Sway 雖大致相容 i3 設定，但作者遇到滑鼠游標延遲、libinput 參數難以對應、偶發快捷鍵像是被觸發兩次，以及最致命的 Xwayland 縮放支援不足導致舊程式模糊或被雙重縮放（讓「先用 Xwayland 撐著」這條退路失效）。他也記錄 GTK 設定（字體縮放、GDK_BACKEND）與字型渲染差異，甚至發現 GTK3 在 Wayland 下偏向只吃 dconf 設定而忽略傳統 `settings.ini`。螢幕鎖定從 i3lock 換到 swaylock，因 Wayland 的 ext-session-lock-v1 協定要求合成器遮蔽輸出，造成 swaylock 若被殺掉會出現「紅畫面」必須重新解鎖；i3 的 IPC（interprocess communication）相關自動化工具也因 Sway 功能缺口（例如不做 layout save/restore、部分比對條件未支援）而需要改寫。終端機方面他偏好 foot，但遇到快捷鍵、URL 選取、screen(1) 顏色（terminfo）等相容性瑕疵；Emacs 則是另一個大痛點：原版多半走 Xwayland（在 Sway 下變模糊），原生 Wayland 需用 Emacs 的 pgtk 版本，卻出現字距/行高不同與明顯輸入延遲，且遠端使用從 X11 forwarding 轉到 waypipe（Wayland 遠端轉送）仍待評估。Chrome 在 Wayland 下初看硬體加速正常，但頻繁移動縮放後 GPU 行程會崩掉，WebGL 等加速失效；此外 Chrome 視窗無法像在 i3/X11 時依 `_NET_WM_DESKTOP` 回到原工作區，對多工作區工作流非常惱人，預期要靠新協定 `xdg-session-management` 改善。螢幕分享則必須靠 xdg-desktop-portal 與 xdg-desktop-portal-wlr（wlroots 的 portal），舊版無法分享「單一視窗」，新版雖可但流程需要額外挑選器、解析度還可能套錯縮放係數導致畫面糊。再加上啟用輸出縮放後切換視窗會短暫「跳動/模糊」的縮放瑕疵，作者結論是：距離「可當日常主力」第一次真的接近了，但以他目前 X11/i3 幾乎零瑕疵、超低延遲的基準來看，改用 Wayland/Sway 仍是純負擔，短期內會繼續留在 X11/i3，並列出需達成的條件（快捷鍵重複、縮放跳動、Chrome 長時間硬體加速穩定、視窗回工作區、以及 Emacs 的縮放/延遲問題）。
討論區的共識大致分裂成兩派：一派認為 Wayland 最大的結構性問題是「它只是協定，不是單一實作」，導致 GNOME（Mutter）、KDE（KWin）、wlroots/Sway/Hyprland 等各自重做大量過去 Xorg 集中提供的功能，還外掛出 xdg-desktop-portal-gnome/kde/wlr/hyprland 等多套 portal，複雜度從「只有一份」搬到「很多份」，除錯與相容性成本被放大；也有人直指這種缺乏共同基礎層的狀態違背了某些人心目中的 UNIX 傳統。針對螢幕分享，留言補充目前「多數螢幕分享都在瀏覽器」卻得依賴 portal/Flatpak 這條路徑，涉及多層 IPC（行程間通訊）與元件，體驗特別容易踩雷；也有人分享 wlroots 系合成器（Sway、niri）日用仍常遇到 Wine、多螢幕、10-bit 等零碎問題，甚至得偶爾切回 GNOME 才能做特定工作。
另一派則強調「其實很多人早就順用」，尤其是 AMD/Intel 顯示卡、或直接用 GNOME/KDE 的使用者，回饋 Wayland 的平滑度、多螢幕不同縮放（fractional scaling，非整數縮放）與切換顯示器的體驗更好；也有人指出 X11 長期維護人力萎縮是現實，桌面環境想甩掉同時維護 X11 與 Wayland 的負擔，才會逐步把 Wayland 變預設，XWayland 則會作為相容層長存。不過討論也提醒：Wayland 的安全模型讓 xdotool、xev、x2x 這類「全域操控/讀取輸入」的自動化工作流變得困難，等於逼部分使用者留在 Xorg；也有人糾正文章中常見的歷史敘事，認為當年 nVidia 與 GBM/EGLStreams 的衝突不完全是「nVidia 不配合」，而是早期 GBM 偏向 Mesa 生態的介面設計導致封閉驅動難以直接採用。整體而言，留言普遍肯定作者把問題具體化、做出可重現案例並回報上游，因為在「預設遷移潮」下，真正能推進相容性的往往就是這種細節扎實的 bug 追查與修補。
👥 68 則討論、評論 💬
https://news.ycombinator.com/item?id=46485989