將 Wayland 合成器與視窗管理員分離

背景

傳統的 Wayland 架構為了修正 X11 顯示伺服器與合成器之間因通訊往返導致的延遲與輸入路由問題，選擇將顯示伺服器、合成器與視窗管理員（Window Manager）整合為單一的單體式程序。然而，這種設計大幅提升了開發門檻，要求視窗管理員必須同時實作複雜的底層合成邏輯。新發布的 river 0.4.0 透過 river-window-management-v1 協定，試圖將視窗管理策略從核心合成器中抽離，讓開發者能更專注於視窗佈局與行為定義。

社群觀點

在 Hacker News 的討論中，許多使用者對於 Wayland 長期以來缺乏「可插拔式視窗管理員」感到不滿，認為這是相較於 X11 最大的退步。支持者指出，在 X11 時代，視窗管理員僅是一個與客戶端通訊的獨立程序，開發門檻極低，甚至能像 Emacs 的 EXWM 套件一樣，直接用 Lisp 實作視窗管理邏輯。但在 Wayland 的單體架構下，即便有 wlroots 等函式庫輔助，開發者仍需處理大量與顯示相關的基礎設施。若合成器本身沒有預留介面，使用者甚至連調整鍵盤佈局等基本功能都無法達成，這種架構上的限制嚴重阻礙了新型桌面環境與視窗管理員的創新。

然而，部分留言者對此持保留態度，並從技術演進的角度為 Wayland 辯護。有觀點認為，Wayland 之所以複雜，是因為它將原本由 X11 承擔的驅動與核心功能交還給了 Linux 核心處理。現代的 Wayland 合成器依賴核心的 DRM 等機制，這比 X11 早期需要自行處理硬體驅動的時代要簡潔得多。針對「開發困難」的質疑，有人反駁即便不拆分程序，開發者仍能透過 wlroots 或 Smithay 等函式庫獲得幫助，且單體化設計是為了確保幀同步（Frame Perfection）與低延遲的必要犧牲。

討論中也出現了關於「外掛式設計」的爭論。有意見認為，視窗管理員不一定要是獨立程序，只要合成器能提供完善的 API 或擴充插件機制即可解決問題。但反對者強調，獨立程序帶來的隔離性與靈活性是插件機制難以企及的。river 的嘗試被視為一種折衷方案，它在維持 Wayland 效能優勢的同時，讓使用者能像在 X11 時代一樣，自由地更換或自定義視窗管理邏輯。例如有使用者分享，在 Hyprland 等單體合成器中難以實現的特定平鋪演算法，透過 river 的拆分架構便能輕鬆達成，這證明了這種架構對進階用戶與開發者的吸引力。

延伸閱讀

在討論中，參與者提到了幾個與 Wayland 開發相關的關鍵資源。wlroots 是目前最流行的 Wayland 合成器開發函式庫，許多非 GNOME/KDE 的合成器皆基於此開發；Smithay 則是另一個以 Rust 語言編寫的合成器實作框架。此外，針對 X11 的維護問題，有留言者提到了 xlibre 專案，雖然其性質在社群中存在爭議，但仍反映了部分使用者對保留 X11 生態系統的渴望。