選型的真正軸線：整合度 vs 組裝自由度

桌面環境的選擇，核心不是「輕或重」，是別人幫你整合好多少、你保留多少自己組裝的自由。這條軸線的一端是 GNOME 這種高整合方案：面板、設定、通知、檔案管理全部設計成一致的整體，你開機就有一台能用的機器，代價是想改動它預設的行為要對抗它的設計哲學。另一端是 Hyprland 這種 compositor：它只負責畫面與視窗，面板、啟動器、鎖屏、通知你全部自己挑自己接，代價是要花時間組裝、每個元件都要自己維護。

「輕/重」只是這條軸線的副產品。高整合方案因為要保證所有元件協同，通常帶較多常駐服務、吃較多記憶體；自己組裝的方案可以只裝你要的，所以輕——但如果你把面板、啟動器、通知、鎖屏一個個補齊，最後的資源佔用未必比一個現成 DE 省多少。所以判選型別問「哪個輕」，要問「我想花多少時間在組裝與維護、換到多少客製自由」。

五個主流選項的定位

下表是常見選項在「整合度」這條軸線上的位置與代價。每個選項底下有延伸說明，因為同樣一句「適合客製」在不同方案裡的實際體驗差很多：

GNOME：把選擇替你做完的現代桌面

GNOME 的定位是「一套有明確設計主張的完整桌面」——它預設一個不同於 Windows/macOS 的工作流（頂欄 + Activities 總覽 + 動態工作區），並且刻意收斂可調選項，讓多數人不用設定就有一致體驗。從 Windows/macOS 轉來、想要「裝好就能用、不想折騰」的人，GNOME 是穩妥選擇：它的整合度最高，通知、設定、線上帳號、檔案管理彼此協調。

代價在客製。GNOME 把很多設定收進 extension 或需要另裝 gnome-tweaks（Arch：pacman -S gnome-tweaks）才改得動的角落，想把它調成傳統工作列風格是在對抗它的設計方向，而 extension 又會隨 GNOME 大版本更新而失效。所以 GNOME 適合「接受它的工作流」的人，不適合「想按自己習慣重排一切」的人。資源上它是這幾個裡偏吃的，老硬體上會感覺得到。

KDE Plasma：整合度高、但幾乎每個角落都能調

KDE Plasma 少見地同時做到高整合與高可調：它像 GNOME 一樣開箱即用、元件協調，但幾乎每個行為都攤在設定介面裡讓你改——面板可以拆解重組、視窗規則、快捷鍵、視覺效果都有深度選項。從 Windows 轉來的人會覺得它的預設隱喻（底部工作列 + 開始選單）親切，又保留了往下鑽的空間。

它的代價不在資源（現代 Plasma 已相當精實，中階機器順暢），在「選項多到需要自己收斂」——設定深意味著你可能花很多時間在調整上。想要「高整合又想保留大量客製、但不想從零組裝」的人，Plasma 通常是比 GNOME 和 Hyprland 都平衡的落點。它的 Wayland session 近年已是預設且成熟。

XFCE：老硬體與「要傳統、要穩、要輕」的預設

XFCE 的定位是輕量而傳統：它給你熟悉的桌面隱喻（工作列、選單、系統匣），資源佔用在這幾個裡最低，且以穩定少變著稱——它不追新，多年來介面與行為變動小。老硬體、低階 VM、或「我只要一個不吵不鬧、能穩定工作的桌面」的場景，XFCE 是可靠預設。

它的取捨是現代感與顯示協定：XFCE 目前仍以 X11 為主，Wayland 化在進行但尚未是預設，所以想要 Wayland 的分數效益（見下節）目前要往別的方案找。客製自由度中等——比 GNOME 開放、但沒有 KDE 那種深度設定，也沒有 Hyprland 那種完全重組的自由。

Cinnamon：給「要 Windows 式熟悉感」的轉移者

Cinnamon 出身 Linux Mint，定位是把傳統桌面隱喻做得順手好上手——底部工作列、開始選單式的應用選單、系統匣，對從 Windows 轉來的人幾乎零學習曲線。它比 XFCE 現代一點、視覺完整度高一些，整合度也高（自帶檔案管理員 Nemo、設定中心、特效）。

代價與 XFCE 類似：以 X11 為主，資源比 XFCE 略高。它適合「要一台立刻上手、像 Windows 但是 Linux」的工作機，不適合追求 Wayland 或極致輕量的場景。附帶一提，Cinnamon 的檔案管理員 Nemo 假設 Cinnamon 桌面服務在旁邊，把它單獨裝進裸 window manager 會拖進整套 Cinnamon 元件——這正是加圖形檔案管理員那篇講的桌面環境耦合。

Hyprland：不是 DE，是你自己組一個桌面

Hyprland 嚴格說不是桌面環境，是一個平鋪式（tiling）Wayland compositor——它只負責畫面合成與視窗排列，面板、啟動器、鎖屏、通知、桌布、音量控制全部不含，要你自己挑元件接上去。選它意味著你接受「從零組裝一個桌面」這件事，換來的是最高的客製自由（每個元件都你選、佈局規則完全你定）和最低的裸資源佔用。

它適合「把配置桌面當成一種投入、想要一套完全長成自己樣子的環境」的人，不適合「只想裝好開始工作」的人。組裝過程本身有相當的學習曲線與維護成本——這也是為什麼本系列用一整個 Rice 設計模組談「選了 Hyprland 之後怎麼把它組起來」。如果你還在「要不要走這條路」的階段，這篇就是那個模組的上游：先確認你要的是組裝自由、而不是開箱即用。

Wayland vs X11：選型時避不開的底層判斷

顯示協定是選型時的一條隱形軸線，因為它決定了一部分未來相容性。Wayland 是較新的顯示協定，設計上更安全、對高 DPI 與多螢幕不同刷新率支援更好，是 Linux 桌面的方向；X11 是沿用數十年的舊協定，相容性最廣但架構老舊、社群維護逐漸收斂到維持模式。GNOME、KDE Plasma、Hyprland 都已預設或原生 Wayland；XFCE、Cinnamon 目前仍以 X11 為主。

實務判讀：如果你用 NVIDIA 專有驅動、或依賴某些只支援 X11 的老工具（部分螢幕錄製、遠端桌面、自動化工具），X11 方案目前可能更少驚喜；如果你要高 DPI 筆電、多螢幕混合刷新率、或想跟上長期方向，優先選 Wayland 方案。這不是非此即彼的道德選擇，是看你的硬體與工具鏈落在哪邊。

依情境選：從你的處境倒推

選型的最後一步是把上面的定位對回你自己的處境，不是背「哪個最好」：

• 剛從 Windows/macOS 轉來、只想要能用：KDE Plasma（熟悉隱喻 + 之後可深調）或 GNOME（接受新工作流、要最省心）。要極致熟悉感就 Cinnamon。
• 老硬體 / 低階 VM / 要穩定不折騰的工作機：XFCE。資源最低、變動最少。
• 想把桌面調成完全自己的樣子、願意投入組裝：Hyprland（或其他 WM）。先讀 Rice 設計模組 確認你要的是這條路。
• 要高整合又要大量客製、不想從零組裝：KDE Plasma，是這兩個需求的平衡點。
• 硬體是 NVIDIA 或依賴 X11 工具：優先 X11 成熟的方案（XFCE / Cinnamon），或確認你的 Wayland 方案在該硬體上的狀況再決定。

判準是把「我願意花多少時間在桌面本身、我對客製的需求有多強、我的硬體與工具落在 Wayland 還是 X11」三個問題答清楚，選項自然收斂。沒有一個 DE 對所有人最好——選錯最常見的原因是拿別人的推薦套自己不同的處境。

桌面環境的擴充生態

選好 DE 之後，各方案還有自己的擴充路徑，這是「選項之下還有選項」的一層：

• GNOME：透過 GNOME Extensions 加面板、工作流、狀態列元件，但要注意 extension 綁 GNOME 版本、大版本更新可能失效。
• KDE Plasma：內建的 widget（plasmoid）、全域主題、視窗規則系統，多數擴充不需要離開設定介面。
• XFCE / Cinnamon：panel plugin、applet、主題，擴充幅度中等但穩定。
• Hyprland：因為本來就是自己組，擴充等於換元件——換 bar（waybar/其他）、換啟動器、換通知 daemon，自由度最高也最需要自己維護。這一整套怎麼組，是 Rice 設計模組 的主題。

下一步

• 選了 Hyprland、要開始組裝：Dotfile 管理：桌面 Rice 設計 是「選了之後怎麼把它長成自己的樣子」的完整模組。
• 桌面選好、要裝檔案管理員這類 GUI app 時的相依判讀：在 Hyprland 加圖形檔案管理員。
• 純終端機環境不需要桌面環境、但需要對應的 CLI 工具：CLI 環境工具。
• 桌面裝好後遇到顯示、鎖屏、服務層的問題怎麼診斷：除錯與診斷。

配置檔位置與格式

Hyprland v0.55 起，配置格式從 hyprlang（.conf）遷移到 Lua（.lua）。主配置檔是 ~/.config/hypr/hyprland.lua。如果 .lua 不存在但 .conf 存在，Hyprland 會回退讀取舊格式，但 hyprlang 已標記為棄用，後續版本會移除支援。

修改後即時生效（不需要重新登入或重啟）。第一次啟動時如果沒有配置檔，Hyprland 會自動產生範例配置。即使配置有語法錯誤，緊急快捷鍵（SUPER+Q 開 terminal、SUPER+M 離開）仍然可用。

[VM 可測試] 配置檔格式和載入行為在 VM 裡跟實機完全相同。

模組化拆分

用 Lua 原生的 require() 拆分配置：

1-- ~/.config/hypr/hyprland.lua — 主入口
2
3require("monitors")      -- 載入 monitors.lua
4require("keybinds")      -- 載入 keybinds.lua
5require("rules")         -- 載入 rules.lua
6require("autostart")     -- 載入 autostart.lua
7require("appearance")    -- 載入 appearance.lua
8require("env")           -- 載入 env.lua

require("monitors") 會從同目錄載入 monitors.lua。拆分的理由是職責分離——改 keybind 不用在千行配置裡找位置，每個子檔案可以獨立 diff 和 rollback。

從舊格式遷移

Hyprland 官方提供遷移工具：hyprlang2lua（Go，也有瀏覽器版）和 hypr-migrate。如果你是從零開始，直接用 Lua 格式。

Monitor 設定

Monitor 設定是硬體相關的核心配置，每台機器都不同。

 1-- ~/.config/hypr/monitors.lua
 2
 3hl.config({
 4    monitor = {
 5        -- 語法："name, resolution@refreshrate, position, scale"
 6        "DP-1, 2560x1440@144, 0x0, 1",
 7        "HDMI-A-1, 1920x1080@60, 2560x0, 1",
 8
 9        -- 筆電內建螢幕
10        "eDP-1, preferred, auto, 1.5",
11
12        -- 預設規則（未明確列出的螢幕）
13        ", preferred, auto, 1",
14
15        -- 鏡像模式（DP-2 鏡像 DP-1 的畫面）
16        -- "DP-2, preferred, auto, 1, mirror, DP-1",
17    },
18})

position 決定多螢幕的空間排列——0x0 是左上角原點，2560x0 表示在第一個螢幕的右邊。scale 處理 HiDPI 顯示（1.5 表示 150% 縮放）。

查詢可用的 monitor 名稱：hyprctl monitors

其他選項：

• transform, 1 — 旋轉（0=正常、1=90 度、2=180 度、3=270 度）
• vrr, 1 — 可變更新率（1=開啟、2=僅全螢幕）
• bitdepth, 10 — 10-bit 色彩

筆電合蓋行為

1-- 合蓋時關閉內建螢幕、開蓋時恢復
2-- bindl = 即使輸入鎖定也能觸發（合蓋時需要）
3hl.bindl("", "switch:on:Lid Switch", "exec", "hyprctl keyword monitor 'eDP-1, disable'")
4hl.bindl("", "switch:off:Lid Switch", "exec", "hyprctl keyword monitor 'eDP-1, preferred, auto, 1'")

[需實機測試] Monitor 位置排列、HiDPI 縮放、VRR、旋轉、多螢幕熱插拔、合蓋行為。VM 通常只有一個虛擬螢幕。

Dotfile 管理策略

Monitor 設定是典型的「機器專屬」配置。如果用 chezmoi，可以用 template 依機器名稱切換；如果用 stow，可以把 monitors.lua 排除在 Git 外、每台機器手動寫。

輸入裝置配置

 1-- ~/.config/hypr/hyprland.lua 或拆到獨立檔案
 2
 3hl.config({
 4    input = {
 5        kb_layout = "us",
 6        -- 多語系：kb_layout = "us,de",
 7        -- 切換：kb_options = "grp:alt_shift_toggle",
 8        -- Caps Lock 當 Escape：kb_options = "caps:escape",
 9        kb_options = "",
10
11        follow_mouse = 1,         -- 焦點跟隨滑鼠
12        sensitivity = 0,          -- -1.0 到 1.0（0 = 不修改）
13        accel_profile = "flat",   -- flat 或 adaptive
14
15        repeat_rate = 25,         -- 長按時每秒重複幾次
16        repeat_delay = 600,       -- 按住多久開始重複（毫秒）
17
18        touchpad = {
19            natural_scroll = true,
20            disable_while_typing = true,
21            ["tap-to-click"] = true,
22            drag_lock = false,
23            scroll_factor = 1.0,
24        },
25    },
26})

可用的 XKB options 查詢：/usr/share/X11/xkb/rules/evdev.lst 或 localectl list-x11-keymap-options。

[VM 可測試] 鍵盤 layout、repeat rate。
[需實機測試] 觸控板設定、手勢、滑鼠靈敏度/加速曲線、多鍵盤配置。

Keybind 設計

修飾鍵（Modifier）：SUPER 是哪顆鍵

keybind 由「修飾鍵 + 按鍵」組成，Hyprland 配置裡最常當主修飾鍵的是 SUPER。SUPER 是 X11/Wayland 對 Meta 鍵的稱呼，在不同鍵盤上是不同的實體鍵：

• PC 鍵盤：Windows 鍵（⊞，通常在 Ctrl 與 Alt 之間）。
• Mac 鍵盤：Command 鍵（⌘）。

其他常見修飾鍵：SHIFT、CTRL（Control）、ALT（Mac 上是 Option ⌥）。組合寫法用空格串，例如 "SUPER SHIFT"。選 SUPER 當主修飾鍵是慣例——它幾乎不跟應用程式本身的快捷鍵衝突（應用多用 Ctrl / Alt）。

在 Mac 上跑虛擬機時，實體 ⌘ 會對應到 guest 的 SUPER，但 macOS 會先攔截部分 ⌘ 組合——這層 VM 專屬的坑見 VM 環境設定。

Bind 類型

Hyprland 提供多種 bind 函式，處理不同互動模式：

[VM 可測試] 所有 keybind 邏輯和配置語法。

基本操作

 1-- ~/.config/hypr/keybinds.lua
 2
 3-- 基本操作
 4hl.bind("SUPER", "Return", "exec", "kitty")
 5hl.bind("SUPER", "Q", "killactive")
 6hl.bind("SUPER", "D", "exec", "wofi --show drun")
 7hl.bind("SUPER", "F", "fullscreen", "0")
 8hl.bind("SUPER SHIFT", "Space", "togglefloating")
 9
10-- 焦點移動（vim 風格）
11hl.bind("SUPER", "H", "movefocus", "l")
12hl.bind("SUPER", "J", "movefocus", "d")
13hl.bind("SUPER", "K", "movefocus", "u")
14hl.bind("SUPER", "L", "movefocus", "r")
15
16-- 視窗移動
17hl.bind("SUPER SHIFT", "H", "movewindow", "l")
18hl.bind("SUPER SHIFT", "J", "movewindow", "d")
19hl.bind("SUPER SHIFT", "K", "movewindow", "u")
20hl.bind("SUPER SHIFT", "L", "movewindow", "r")
21
22-- 視窗大小調整（長按連續觸發）
23hl.binde("SUPER CTRL", "H", "resizeactive", "-20 0")
24hl.binde("SUPER CTRL", "J", "resizeactive", "0 20")
25hl.binde("SUPER CTRL", "K", "resizeactive", "0 -20")
26hl.binde("SUPER CTRL", "L", "resizeactive", "20 0")
27
28-- 滑鼠綁定：SUPER + 左鍵拖曳移動、右鍵拖曳調整大小
29hl.bindm("SUPER", "mouse:272", "movewindow")
30hl.bindm("SUPER", "mouse:273", "resizewindow")
31
32-- Workspace 切換
33hl.bind("SUPER", "1", "workspace", "1")
34hl.bind("SUPER", "2", "workspace", "2")
35hl.bind("SUPER", "3", "workspace", "3")
36hl.bind("SUPER", "4", "workspace", "4")
37hl.bind("SUPER", "5", "workspace", "5")
38hl.bind("SUPER", "6", "workspace", "6")
39hl.bind("SUPER", "7", "workspace", "7")
40hl.bind("SUPER", "8", "workspace", "8")
41hl.bind("SUPER", "9", "workspace", "9")
42
43-- 把視窗送到指定 workspace
44hl.bind("SUPER SHIFT", "1", "movetoworkspace", "1")
45hl.bind("SUPER SHIFT", "2", "movetoworkspace", "2")
46hl.bind("SUPER SHIFT", "3", "movetoworkspace", "3")
47-- 以此類推
48
49-- 螢幕截圖
50hl.bind("", "Print", "exec", "grimblast copy area")
51hl.bind("SUPER", "Print", "exec", "grimblast copy output")
52
53-- 多螢幕焦點切換
54hl.bind("SUPER", "comma", "focusmonitor", "l")
55hl.bind("SUPER", "period", "focusmonitor", "r")
56hl.bind("SUPER SHIFT", "comma", "movewindow", "mon:l")
57hl.bind("SUPER SHIFT", "period", "movewindow", "mon:r")

設計原則

• SUPER（Windows/Command 鍵）當 modifier，避免跟應用程式快捷鍵衝突
• 方向操作統一用 vim 的 HJKL，降低記憶負擔
• modifier 分層：SUPER 是焦點、SUPER+SHIFT 是移動、SUPER+CTRL 是調整大小
• 常用操作（開 terminal、關視窗、切 workspace）放在最順手的位置

Submap：模態快捷鍵

Submap 類似 vim 的模式切換——進入某個 submap 後，快捷鍵的意義改變，直到離開。適合需要連續操作的場景（如調整大小）：

 1-- 按 SUPER+R 進入 resize 模式
 2hl.bind("SUPER", "R", "submap", "resize")
 3
 4-- 定義 resize 模式的快捷鍵
 5hl.submap("resize")
 6hl.binde("", "H", "resizeactive", "-20 0")
 7hl.binde("", "L", "resizeactive", "20 0")
 8hl.binde("", "K", "resizeactive", "0 -20")
 9hl.binde("", "J", "resizeactive", "0 20")
10hl.bind("", "escape", "submap", "reset")   -- Escape 離開
11hl.submap("reset")

進入 resize 模式後，直接按 HJKL（不需要 modifier）就能持續調整大小，按 Escape 回到正常模式。

媒體鍵與硬體鍵

 1-- 音量（鎖屏時也能用、長按連續觸發）
 2hl.bindel("", "XF86AudioRaiseVolume", "exec", "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+")
 3hl.bindel("", "XF86AudioLowerVolume", "exec", "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-")
 4hl.bindl("", "XF86AudioMute", "exec", "wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle")
 5hl.bindl("", "XF86AudioMicMute", "exec", "wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle")
 6
 7-- 亮度
 8hl.bindel("", "XF86MonBrightnessUp", "exec", "brightnessctl s 10%+")
 9hl.bindel("", "XF86MonBrightnessDown", "exec", "brightnessctl s 10%-")
10
11-- 媒體播放
12hl.bindl("", "XF86AudioPlay", "exec", "playerctl play-pause")
13hl.bindl("", "XF86AudioNext", "exec", "playerctl next")
14hl.bindl("", "XF86AudioPrev", "exec", "playerctl previous")

[需實機測試] 媒體鍵（XF86Audio*）、亮度鍵（XF86MonBrightness*）、合蓋開關——這些依賴實體硬體送出正確的 keycode。VM 鍵盤通常沒有這些鍵。

環境變數

環境變數在 hl.config() 的 env 區段設定，影響 Hyprland 自身和其下執行的應用程式：

 1-- ~/.config/hypr/env.lua
 2
 3hl.config({
 4    env = {
 5        -- 游標主題
 6        "XCURSOR_SIZE, 24",
 7        "XCURSOR_THEME, Bibata-Modern-Classic",
 8        "HYPRCURSOR_SIZE, 24",
 9        "HYPRCURSOR_THEME, Bibata-Modern-Classic",
10
11        -- Qt 應用程式
12        "QT_AUTO_SCREEN_SCALE_FACTOR, 1",
13        "QT_QPA_PLATFORM, wayland;xcb",
14        "QT_QPA_PLATFORMTHEME, qt5ct",
15        "QT_WAYLAND_DISABLE_WINDOWDECORATION, 1",
16
17        -- GTK 應用程式
18        "GDK_BACKEND, wayland,x11,*",
19
20        -- XDG session
21        "XDG_CURRENT_DESKTOP, Hyprland",
22        "XDG_SESSION_TYPE, wayland",
23        "XDG_SESSION_DESKTOP, Hyprland",
24
25        -- Electron 應用程式（VS Code, Discord 等）
26        "ELECTRON_OZONE_PLATFORM_HINT, auto",
27
28        -- Firefox
29        "MOZ_ENABLE_WAYLAND, 1",
30    },
31})

NVIDIA 專用環境變數

如果使用 NVIDIA 顯卡，需要額外設定（AMD 和 Intel 不需要）：

 1-- 只在 NVIDIA 機器上加這些
 2hl.config({
 3    env = {
 4        "LIBVA_DRIVER_NAME, nvidia",
 5        "GBM_BACKEND, nvidia-drm",             -- Firefox 若崩潰就移除這行
 6        "__GLX_VENDOR_LIBRARY_NAME, nvidia",
 7        "NVD_BACKEND, direct",
 8    },
 9    cursor = {
10        no_hardware_cursors = true,             -- NVIDIA 常見的游標問題修正
11        allow_dumb_copy = true,
12    },
13})

[VM 不適用] NVIDIA 環境變數和驅動設定在 VM 裡無意義——VM 使用 virtio-gpu 或軟體渲染。這些設定只在實體 NVIDIA 機器上測試。

VM 專用環境變數

在 VM（UTM/QEMU）裡跑 Hyprland 需要額外的回退設定：

1-- 只在 VM 裡加，實機要移除
2hl.config({
3    env = {
4        "WLR_RENDERER_ALLOW_SOFTWARE, 1",
5        "LIBGL_ALWAYS_SOFTWARE, 1",
6        "WLR_NO_HARDWARE_CURSORS, 1",
7    },
8})

[已驗證] Hyprland 0.55（Aquamarine 渲染後端）+ UTM virtio-gpu-gl-pci 實測：使用 GPU 加速時不需要 WLR_RENDERER 或 LIBGL_ALWAYS_SOFTWARE，Hyprland 自動走 VirGL/Venus 硬體路徑。WLR_NO_HARDWARE_CURSORS 仍需要（virtio-gpu 不支援硬體 cursor）。完整 VM 設定見 VM 環境設定與測試矩陣。

X11（X Window System）是用了三十多年的傳統協議。成熟、穩定、所有工具都支援。設計上的根本問題是安全性——任何 X11 應用程式都能讀取其他視窗的內容和鍵盤輸入，這是協議層的限制，不是 bug。

Wayland 是設計來取代 X11 的新協議。每個應用程式只看得到自己的視窗、效能更好、對現代硬體的支援更完整。多數主流發行版已經把 Wayland 設為預設，但部分老舊應用程式和特殊需求（某些螢幕錄製、遠端桌面工具）的支援還在追趕中，這些情境會透過 XWayland（相容層）跑 X11 應用程式。

新的 tiling WM 主要基於 Wayland 開發，X11 上的老牌（i3, bspwm, dwm）仍然活躍但不再是未來方向。

主流 Tiling WM

i3（X11）/ sway（Wayland） 是社群最大、文件最齊全、行為最可預測的選擇。i3 跑在 X11 上，sway 是它的 Wayland 移植，配置格式幾乎相同。配置檔用自己的語法，直覺的 key = action 對應。

1# sway/config 片段
2set $mod Mod4
3bindsym $mod+h focus left
4bindsym $mod+j focus down
5bindsym $mod+k focus up
6bindsym $mod+l focus right
7bindsym $mod+Shift+h move left
8bindsym $mod+1 workspace number 1
9bindsym $mod+2 workspace number 2

穩定性是 i3/sway 最大的賣點——配置寫好之後很少因為更新而壞掉。適合想要可靠的平鋪工作流、不需要華麗視覺效果的人。

Hyprland（Wayland） 吸引的是在意桌面視覺品質的平鋪使用者——看 r/unixporn 的 Hyprland 截圖就知道，流暢的視窗切換動畫、圓角、視窗模糊、漸層邊框，這些傳統 tiling WM 社群視為不必要的裝飾，Hyprland 做成內建功能並且認真打磨。配置檔改完即時生效（hot reload），迭代調教的回饋循環很短。

這份視覺投入換來的 trade-off 是穩定性。開發節奏快意味著偶爾會有 breaking changes——某次更新後配置語法改了（2026 年 4 月的 Lua 遷移就是一例）、某個選項改名或移除。把它當主力桌面，要有「更新後可能要回來調配置」的心理準備。Hyprland 配置會詳細講它的設定。

bspwm（X11） 是純粹的 BSP 樹狀分割。它只做一件事：管理視窗的樹狀結構。所有操作透過 bspc 命令列工具驅動，快捷鍵綁定交給 sxhkd（一個獨立的快捷鍵 daemon）。UNIX 哲學——每個工具只做一件事，組合起來用。

dwm（X11） 極簡到配置要改 C 原始碼然後重新編譯。不是給「想要方便配置」的人用的，而是給「想要完全理解自己桌面每一行程式碼」的人用的。

拼裝式桌面的代價

Linux tiling WM 的桌面是你自己拼出來的：compositor（Hyprland/sway）負責視窗管理、狀態列（waybar）負責頂部資訊條、啟動器（rofi/wofi）負責 app 搜尋啟動、通知（mako/dunst）負責通知彈窗、鎖屏另外裝。每一塊是不同專案、不同作者。

好處是每一塊都可以換。壞處是當某件事壞了，你要自己判斷是哪一層的問題。藍牙選單不能點？可能是狀態列的 module 設定錯、可能是 blueman 沒跑、可能是 D-Bus session 有問題。完整桌面環境（KDE/GNOME）幫你整合測試過了，拼裝式桌面沒有這層保障。

多螢幕的處理

多螢幕是自動平鋪比較能展現價值的場景。每個螢幕是獨立的平鋪區域，視窗在哪個螢幕就在那個螢幕的範圍內平鋪。

快捷鍵跨螢幕操作是標配功能：把焦點跳到另一個螢幕、把當前視窗丟到另一個螢幕（丟過去後自動融入那邊的平鋪佈局）。三螢幕時這個便利性比單螢幕更明顯——純滑鼠拖視窗跨螢幕需要的移動距離很長。

工作區跟螢幕的綁定方式是各工具差異最大的地方。

macOS 的 Spaces 是綁定螢幕的——每個螢幕有自己獨立的一組 Spaces。yabai 沿用這個行為，切換工作區時只影響當前螢幕。AeroSpace 用自己的虛擬工作區繞過 macOS 原生 Spaces 的限制，多螢幕操作被普遍認為更穩定、更直覺。

Hyprland 的 workspace 可以動態指派到不同螢幕——workspace 3 現在在螢幕 A，你可以把它移到螢幕 B。這種模型彈性最大，但也需要清楚的心智模型來管理「哪個 workspace 在哪」。

熱插拔螢幕（接上、拔掉外接螢幕）是各工具的常見痛點。拔掉螢幕時，該螢幕上的視窗要搬到剩餘螢幕重新平鋪；插上螢幕時，佈局要擴展。多數工具有對應設定（記住螢幕配置、自動還原佈局），但體驗不見得完美，偶爾需要手動整理。

Dotfile 中的視窗管理配置

視窗管理是 dotfile 管理裡「桌面層」的核心。WM 配置檔決定了整個桌面的操作邏輯——快捷鍵怎麼綁、視窗間距多大、哪些 app 要浮動、工作區怎麼分配。

macOS 工具的配置檔通常是一個檔案：AeroSpace 的 ~/.aerospace.toml、yabai 的 ~/.yabairc + ~/.skhdrc、Amethyst 的 ~/.amethyst.yml。把這些檔案放進 dotfile repo，換 Mac 時就能還原整套視窗管理行為。

Linux tiling WM 的配置在 ~/.config/ 下，通常是一個資料夾：Hyprland 的 ~/.config/hypr/、sway 的 ~/.config/sway/、i3 的 ~/.config/i3/。除了 WM 本身，狀態列（waybar 的 ~/.config/waybar/）、啟動器（rofi 的 ~/.config/rofi/）、通知（mako 的 ~/.config/mako/）等周邊元件的配置也各自有檔案。一套完整的 Linux 平鋪桌面，dotfile repo 裡可能會有十幾個配置目錄——這也是為什麼 Linux 桌面客製化社群那麼依賴 dotfile 管理工具（見管理工具與目錄結構）。

跟螢幕硬體綁定的設定（螢幕解析度、縮放比、螢幕排列順序）通常也寫在 WM 配置裡。這部分在跨機器搬移 dotfile 時需要調整——同一份 Hyprland 配置裡的 monitor 設定，在筆電上是一個螢幕、在桌機上可能是三個。常見做法是把硬體相關設定拆到單獨檔案（如 monitors.lua），主配置用 require 引入，這樣跨機器時只需要替換這一個檔案。同步與環境重建會講跨機器搬移時怎麼處理這類硬體差異。

Workspace 設定

Workspace 是平鋪式桌面的空間管理單位。Hyprland 的 workspace 是動態的——不需要預先定義多少個，按了不存在的 workspace 編號就會自動建立。

 1-- 把特定 workspace 綁定到特定螢幕
 2hl.config({
 3    workspace = {
 4        "1, monitor:DP-1, default:true",
 5        "2, monitor:DP-1",
 6        "3, monitor:DP-1",
 7        "7, monitor:HDMI-A-1, default:true",
 8        "8, monitor:HDMI-A-1",
 9        "9, monitor:HDMI-A-1",
10    },
11})

常見的使用模式：

• Workspace 1-3 放在主螢幕（寫程式用）
• Workspace 7-9 放在副螢幕（瀏覽器、通訊軟體、監控）
• 用鍵盤瞬間切換（SUPER + 數字鍵），比 alt-tab 在一堆視窗裡找快

Per-workspace layout 覆寫

1hl.config({
2    workspace = {
3        "1, layoutopt:orientation:left",     -- workspace 1 用左側 master
4        "2, layoutopt:orientation:top",      -- workspace 2 用頂部 master
5    },
6})

[VM 可測試] Workspace 切換、綁定邏輯、per-workspace layout。
[需實機測試] Workspace 綁定到特定實體螢幕的行為。

Window Rules

Window rules 讓特定應用程式在開啟時自動套用設定——指定 workspace、強制浮動、設定大小等。

 1hl.config({
 2    windowrule = {
 3        -- 特定 app 自動送到指定 workspace
 4        "workspace 8, class:^(firefox)$",
 5        "workspace 9, class:^(Slack)$",
 6
 7        -- 設定面板、對話框等維持浮動（不進平鋪）
 8        "float, class:^(pavucontrol)$",
 9        "float, class:^(nm-connection-editor)$",
10        "float, title:^(Open File)$",
11        "float, title:^(Save As)$",
12
13        -- Picture-in-picture 浮動 + 置頂 + 固定大小
14        "float, title:^(Picture-in-Picture)$",
15        "pin, title:^(Picture-in-Picture)$",
16        "size 480 270, title:^(Picture-in-Picture)$",
17        "move 100%-490 50, title:^(Picture-in-Picture)$",
18
19        -- 視窗透明度（active inactive）
20        "opacity 0.9, class:^(kitty)$",
21        "opacity 0.85 0.75, class:^(Code)$",
22
23        -- 防止 Electron app 自動最大化
24        "suppressevent maximize, class:.*",
25
26        -- XWayland video bridge（螢幕分享用）
27        "opacity 0.0 override, class:^(xwaylandvideobridge)$",
28        "noanim, class:^(xwaylandvideobridge)$",
29        "noinitialfocus, class:^(xwaylandvideobridge)$",
30        "maxsize 1 1, class:^(xwaylandvideobridge)$",
31        "noblur, class:^(xwaylandvideobridge)$",
32    },
33})

查詢應用程式的 class 和 title

1hyprctl clients          # 列出所有開啟的視窗（含 class、title、PID 等）
2hyprctl activewindow     # 當前焦點視窗的資訊

Window rules 用 regex 匹配 class 和 title。靜態 rules 匹配的是視窗開啟時的初始值（initialTitle / initialClass）。

Window rules 是讓平鋪式桌面「不只是把所有東西硬塞格子」的關鍵——識別哪些 app 適合浮動、哪些適合指定位置，需要累積使用經驗。

[VM 可測試] Window rules 邏輯、workspace 指派、float 規則。查 class/title 也在 VM 裡能做。

Layout 配置

Dwindle

每個新視窗把當前區域一分為二（螺旋式切分），適合不固定視窗數量的工作流：

1hl.config({
2    dwindle = {
3        pseudotile = true,       -- 允許 app 請求 pseudo-tiling（保留原始大小）
4        preserve_split = true,   -- 不自動改變分割方向
5        force_split = 2,         -- 0=跟隨滑鼠, 1=永遠左/上, 2=永遠右/下
6        smart_split = false,
7        smart_resizing = true,
8    },
9})

Master

一個主區域 + 其餘視窗堆疊在側邊，適合「一個主力視窗 + 多個參考視窗」的模式：

1hl.config({
2    master = {
3        new_on_top = false,       -- 新視窗放 master 還是 stack
4        orientation = "left",     -- master 區域位置：left / right / top / bottom / center
5        mfact = 0.55,             -- master 區域佔螢幕的比例
6    },
7})

在 general 裡設定預設 layout：

1hl.config({
2    general = {
3        layout = "dwindle",       -- 或 "master"
4    },
5})

[VM 可測試] Layout 切換和參數調整的行為邏輯。

外觀設定

 1hl.config({
 2    general = {
 3        gaps_in = 5,
 4        gaps_out = 10,
 5        border_size = 2,
 6        ["col.active_border"] = "rgba(89b4faee) rgba(cba6f7ee) 45deg",
 7        ["col.inactive_border"] = "rgba(313244aa)",
 8    },
 9    decoration = {
10        rounding = 8,
11
12        blur = {
13            enabled = true,
14            size = 5,             -- 模糊半徑（越高越模糊、越吃 GPU）
15            passes = 2,           -- 模糊次數（越多越平滑、越重）
16            vibrancy = 0.17,
17            noise = 0.02,
18            new_optimizations = true,
19        },
20
21        shadow = {
22            enabled = true,
23            range = 15,
24            render_power = 3,     -- 1-4，衰減曲線
25            color = "0xee1a1a2e",
26        },
27
28        dim_inactive = false,
29        dim_strength = 0.2,
30
31        active_opacity = 1.0,
32        inactive_opacity = 0.95,
33    },
34})

[需實機測試] blur 的效能影響和視覺品質——這是 Hyprland 最吃 GPU 的功能。VM 裡建議 blur = { enabled = false } 避免卡頓。shadow 和 rounding 在軟體渲染下可以動但會很慢。

動畫設定

 1-- 定義 bezier 曲線
 2hl.animation("bezier", "ease", 0.25, 0.1, 0.25, 1)
 3hl.animation("bezier", "overshot", 0.05, 0.9, 0.1, 1.05)
 4
 5-- Spring 物理動畫（較新的替代方案）
 6hl.animation("spring", "bouncy", 1, 8, 0)   -- damping, frequency, speed
 7
 8-- 套用動畫
 9hl.animation("animation", "windows", 1, 4, "ease", "slide")
10hl.animation("animation", "windowsOut", 1, 4, "ease", "popin 80%")
11hl.animation("animation", "fade", 1, 3, "ease")
12hl.animation("animation", "workspaces", 1, 4, "ease", "slide")
13
14-- 關閉特定動畫
15hl.animation("animation", "windowsMove", 0)

VM 裡跑 Hyprland 時，建議完全關閉動畫以維持可用的操作速度：

1hl.config({
2    animations = {
3        enabled = false,
4    },
5})

[需實機測試] 動畫流暢度是 Hyprland 的核心賣點，只有實機能評估。VM 裡的卡頓是 GPU 加速不足造成的，不代表 Hyprland 本身的效能。

Autostart

 1hl.config({
 2    exec_once = {
 3        -- 桌面元件
 4        "waybar",
 5        "mako",
 6        "hyprpaper",
 7
 8        -- 系統服務
 9        "/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1",
10        "wl-paste --type text --watch cliphist store",
11
12        -- Idle daemon（閒置鎖屏，鎖屏安全模型見 session-lock 卡）
13        "hypridle",
14    },
15})

exec_once 只在 Hyprland 啟動時跑一次（config reload 不會重複執行）。如果需要每次 reload 都重跑某個指令，用 exec（但多數情況不需要）。

Plugin 系統

Hyprland 用 hyprpm（Hyprland Plugin Manager）管理 plugin：

1hyprpm update                                              # 更新 plugin index
2hyprpm add https://github.com/hyprwm/hyprland-plugins     # 加入官方 plugin repo
3hyprpm enable hyprexpo                                     # 啟用 plugin
4hyprpm disable hyprexpo                                    # 停用 plugin
5hyprpm list                                                # 列出可用 plugin

Plugin 的配置寫在 hyprland.lua 裡，是 dotfile 的一部分。

[VM 可測試] 不依賴 GPU 的 plugin（hy3、hyprbars）。
[需實機測試] 視覺特效類 plugin（hyprexpo、hyprspace、hyprtrails）。

Dotfile 結構對應

Hyprland 的配置拆成多個 .lua 檔，全部放在同一個 stow package 裡。monitors.lua 是硬體相關的——跨機器搬移時可能要排除或用 template/local 機制處理（見跨平台共用一個 Repo）：

 1~/dotfiles/
 2└── hyprland/
 3    └── .config/
 4        └── hypr/
 5            ├── hyprland.lua       # 主入口（只有 require 行）
 6            ├── monitors.lua       # 硬體相關、可能排除或 template
 7            ├── keybinds.lua
 8            ├── rules.lua
 9            ├── autostart.lua
10            ├── appearance.lua
11            └── env.lua

穩定性與維護的務實面

Hyprland 的開發節奏快、功能更新激進。v0.55 的 Lua 遷移就是一個典型案例——配置格式整個換掉，舊的 .conf 只會再支援一到兩個版本。配置檔的語法和可用選項會隨版本變動。

應對策略：

• 更新前先看 Hyprland wiki 的 Configuring 頁面和 changelog
• dotfile repo 的 commit message 記錄「因應 Hyprland vX.Y 改了什麼設定」
• 如果用 Arch 的 rolling release，pacman -Syu 前先確認 Hyprland 是否有 breaking change（Arch 社群通常會在論壇預警）
• 官方提供遷移工具（如 hyprlang2lua），格式變更時優先使用

這是視窗管理與平鋪式工作流提過的代價——把日常桌面建立在高速移動的專案上，持續的配置維護是實際成本。

VM 與實機測試對照

Wayland 是協議，不是軟體

一個常見的誤解是把 Wayland 當成「一個程式」。Wayland 是一份協議規格（protocol specification），描述了 client（應用程式）和 compositor（負責合成畫面的東西）之間怎麼傳遞 buffer、怎麼處理輸入事件。

每個 Wayland compositor 同時扮演三個角色：display server（管理顯示輸出）、window manager（管理視窗排列）、compositor（合成最終畫面）。X11 的世界裡這三個角色是分開的，Wayland 把它們統一成一個程式。這個「三合一」定位的濃縮版與它在故障排除中的責任邊界，見 Compositor 術語卡。

「Hyprland 是 Wayland compositor」這個說法的意思是：它不只是一個視窗管理器，它同時是整個圖形系統的核心。

X11 vs Wayland 架構差異

X11 的三角架構（1984 年設計）

1應用程式 ──→ X Server（中央仲介）──→ Compositor ──→ 螢幕
2             ↑                         ↑
3             └── 輸入事件 ──────────────┘

X Server 是一個龐大的中央仲介，負責接收所有應用程式的繪圖指令、管理輸入事件、再把畫面交給 compositor 做最終合成。Compositing 是後來才加上去的（Compiz、picom 這些都是外掛的 compositor），不是 X11 原始設計的一部分。

Wayland 的直接模型（2008 年設計）

1應用程式 ──→ Compositor（= display server + window manager）──→ 螢幕
2             ↑
3             └── 輸入事件

應用程式用 OpenGL/Vulkan 自己渲染畫面到 buffer，然後把 buffer 直接交給 compositor。沒有中間人。compositor 收到所有 client 的 buffer 後合成最終畫面輸出到螢幕。

這個架構上的差異帶來三個實際影響：效能、安全、screen tearing。

安全性

X11 的安全模型有一個根本性的設計缺陷：任何連到同一個 X Server 的 client，都能監聽其他 client 的鍵盤輸入、擷取其他視窗的畫面、甚至注入假的輸入事件。這代表一個惡意程式可以輕易做到 keylogging——記錄你在其他視窗打的所有字，包括密碼。

Wayland 從協議層就隔離了 client 之間的存取。每個應用程式只看得到自己的 buffer，無法存取其他視窗的內容或輸入。要做 screen capture 或 screen sharing，必須透過 xdg-desktop-portal 這個受控的中介機制，使用者會看到明確的授權提示。

對 tiling WM 的使用者來說，這個安全差異特別有意義：平鋪式桌面通常同時開大量終端機視窗（有些跑 SSH、有些在 sudo 操作），X11 下任何一個視窗裡的惡意程式都能讀到其他視窗的鍵盤輸入。Wayland 阻斷了這條攻擊路徑。

效能與 Screen Tearing

X11 的渲染路徑有多餘的記憶體複製——應用程式把繪圖指令送給 X Server，X Server 渲染後再交給 compositor，compositor 再合成。Wayland 省掉了中間那一步：應用程式直接渲染到 buffer、直接交給 compositor，記憶體複製更少。

Screen tearing（畫面撕裂）在 X11 上是長年的老問題——需要 compositor + vsync 的各種 workaround。Wayland 在協議層就處理了 frame presentation 的時機，compositor 控制什麼時候把合成好的畫面送到螢幕，原生消除 tearing。這也是為什麼 Hyprland 的動畫能跑得流暢——直接 rendering + 原生 vsync 的組合，在 X11 上需要大量額外配置才能接近的效果。

XWayland：X11 相容層

很多應用程式仍然只支援 X11 協議。XWayland 是一個 X11 server，但它本身作為一個 Wayland client 運行——X11 應用程式連到 XWayland，以為自己在跟正常的 X Server 溝通；XWayland 把 X11 協議翻譯成 Wayland 協議，把 buffer 交給 compositor。

多數 Wayland compositor（包括 Hyprland）預設啟用 XWayland，X11 應用程式不需要任何設定就能運行。

需要 XWayland 的常見應用

• 舊版 Electron 應用（新版可用 --ozone-platform=wayland 旗標切換到 Wayland 原生）
• Java 應用程式（NetBeans 等）
• 舊的 GTK2 應用程式
• 部分 Wine/Proton 遊戲（但 XWayland 下的遊戲效能已經相當好）
• 未啟用 PGTK 的舊版 Emacs build（Emacs 29+ 的 PGTK 後端已原生支援 Wayland）

XWayland 的已知問題

最大的實務痛點是 HiDPI 非整數縮放。在 150%、125% 等非整數 scale 下，XWayland 應用程式可能出現模糊渲染，因為 XWayland 不支援 fractional scaling 協議。整數縮放（100%、200%）則沒有問題。

關鍵 Wayland 協議

wlr-layer-shell

Layer-shell 定義了 client 可以在螢幕的哪個「層」上建立畫面——background（最底）、bottom、top、overlay（最頂）。Status bar（waybar）、notification daemon（mako）、launcher（wofi）、wallpaper（hyprpaper）、lock screen（hyprlock）都透過 layer-shell 來佔據螢幕空間。

沒有 layer-shell 支援的 compositor，這些桌面元件就無法運作。這也是為什麼桌面 Rice 設計的所有工具都只能在支援 layer-shell 的 Wayland compositor 上跑——它是可組裝式桌面的基礎設施。

xdg-desktop-portal

Portal 是一個 D-Bus 介面，讓被隔離的 Wayland 應用程式可以請求特權操作：screen sharing、檔案對話框、螢幕截圖。每個 compositor 提供自己的 portal backend：

• Hyprland：xdg-desktop-portal-hyprland
• GNOME：xdg-desktop-portal-gnome
• KDE：xdg-desktop-portal-kde
• Sway/wlroots 系：xdg-desktop-portal-wlr

Screen sharing 的完整鏈路是：PipeWire + xdg-desktop-portal-hyprland。OBS 的 PipeWire source、瀏覽器的畫面分享，都走這條路。

wlroots 與 Hyprland 的關係

wlroots 是一個模組化的 C library，提供 Wayland compositor 的共用基礎建設——輸入處理、輸出管理、協議實作。Sway、river、wayfire 這些 compositor 都基於 wlroots 開發，共享同一套底層程式碼。

Hyprland 最初也基於 wlroots，但後來 fork 出去自己維護底層。這讓 Hyprland 可以更快地加入新功能（動畫、模糊、漸層邊框），不需要等 wlroots 上游審核。代價是 Hyprland 的更新不再跟 wlroots 生態同步，偶爾會有相容性差異。

2026 年的 Wayland 採用現況

Wayland 在 2026 年已經從「取代 X11 的方向」變成「Linux 桌面的預設」：

X11 上的老牌 tiling WM（i3、bspwm、dwm）仍然活躍，但不再是新專案的主流方向。新的 tiling WM 幾乎都選擇 Wayland 作為基礎。

X11 仍有優勢的場景

Wayland 並非在所有面向都超越 X11：

• SSH X forwarding：X11 原生支援透過網路轉送 GUI 視窗（ssh -X）。Wayland 沒有對等機制，替代方案是 waypipe，但不是 drop-in replacement
• 跨 compositor 的 GUI 自動化：xdotool、wmctrl 在 X11 上可以操控任何 WM 的視窗。Wayland 沒有跨 compositor 的通用對應方案——每個 compositor 提供自己的 IPC 工具。不過 Hyprland 的 hyprctl 在 Hyprland 環境內提供了比 xdotool 更豐富的能力：socket-based IPC、JSON 格式查詢所有視窗和工作區狀態、即時 dispatch 動作、event 監控（hyprctl socket2）。瓶頸在「跨 compositor 通用」，不在單一 compositor 內的功能深度
• VNC / 遠端桌面：X11 的網路透明性讓遠端桌面相對簡單。Wayland 需要 PipeWire + portal，設定複雜度更高
• Color management：專業色彩工作流（ICC profile 管理）在部分 Wayland compositor 上仍需手動配置

這些場景如果是你的核心需求，目前 X11（或 X11-based 的 i3/sway 的 X11 版本）可能仍是更務實的選擇。

為什麼 Tiling WM 使用者該關心 Wayland

平鋪式桌面是「自己從元件組裝桌面」的工作流。Wayland 的幾個特性讓這件事變得更好：

layer-shell 給了 status bar、launcher、notification daemon 一個標準化的方式來佔據螢幕空間，不再需要各種 hack 讓這些元件「浮在視窗上面又不被平鋪規則管到」。

安全隔離在多終端機場景特別有價值——平鋪式桌面通常同時開著 SSH session、密碼管理器、sudo 操作，Wayland 確保任何一個視窗裡的程式都無法偷看其他視窗的鍵盤輸入。

直接 rendering 讓 Hyprland 能做到流暢的視窗動畫和即時模糊，這在 X11 上需要大量額外的 compositor 配置（picom + 各種 backend 選擇 + vsync 調校）才能接近。

從實務角度看：2026 年開始接觸 Linux tiling WM，選 Wayland-based 的工具（Hyprland、Sway）是順流而行。X11 不會立刻消失，但新功能、新工具、社群活力都在 Wayland 這一邊。

視窗管理與平鋪式工作流講了平鋪概念和選型，這裡直接進入 Hyprland 的配置實務。之後的 VM 實測專案會用這些配置做實際安裝和驗證。

macOS 讀者如果不打算在 Linux 或 VM 上跑 Hyprland，可以跳到同步、Bootstrap 與環境重建——bootstrap script 和 secret 管理的概念對 macOS 同樣適用。

章節文章

跨分類引用

• → 模組四：視窗管理與自動平鋪：平鋪式 WM 的概念和選型
• → 模組六：桌面 Rice 設計：compositor 之上的狀態列、啟動器、通知、配色系統
• → 模組七：桌面環境維護與故障排除：Hyprland crash、GPU hang、config 寫錯時的診斷和恢復
• → 模組八：同步、Bootstrap 與環境重建：跨機器搬移時硬體相關設定怎麼處理
• → Linux 工具選單：圖形桌面工具：在 Hyprland 下加圖形檔案管理員（Thunar / Nemo / PCManFM-Qt）的相依取捨

跟 X11 的分工對照能看清它的定位。X11 時代，X server 負責畫面、一個獨立的 window manager 負責視窗排列，兩者透過協定溝通；Wayland 取消這個分家，compositor 直接兼任兩者。所以在 Wayland 語境裡，「compositor」和「window manager」常指同一個東西——Hyprland 既是 compositor 也是 tiling window manager。

它跟桌面環境（desktop environment）是不同層次。桌面環境（GNOME、KDE）是一整套元件（面板、設定、通知、檔案管理），其中內含一個 compositor；而 Hyprland 這類「只有 compositor」的方案不含那圈桌面服務，面板、啟動器、鎖屏都要另外自己接。這條「整合度 vs 自己組裝」的軸線，是桌面環境選型的主題。

compositor 在故障排除中是一個關鍵的責任邊界，因為多個系統狀態由它持有、而非別的層：

• 它握著 DRM master：直接畫到顯示裝置的獨佔權由 compositor 持有，這是為什麼 compositor 必須從實體圖形 VT 起、不能從 SSH pty 起（SSH 連線裡沒有那個 seat 與 DRM 資源），也是為什麼它跟同樣要畫到 DRM 的 kmscon 之類 userspace console 會相衝。
• 它持有 session lock 狀態：Wayland 的 ext-session-lock 鎖是 compositor 層的狀態、跟 logind 獨立，殺掉鎖屏程式 compositor 仍保持鎖定——詳見 Session Lock。
• 它掛了、桌面才真的黑：反過來說，只要 kernel 還活著、compositor 以外的東西壞了，TTY 仍能登入操作。判斷「畫面黑」是 compositor 掛了、還是沒 getty、還是顯示輸出沒接，是桌面故障排除的第一個分岔。

相關概念：TTY（不依賴 compositor 的救生通道）、Session Lock（compositor 持有的鎖定狀態）、Rice（在 compositor 上做視覺客製）。

Wayland 下的 compositor（如 Hyprland、Sway）同時管理視窗排列與畫面輸出。鎖屏工具（Hyprlock、Swaylock）一旦啟動，桌面的「鎖定」狀態就由 compositor 透過 ext-session-lock-v1（Wayland 生態系的跨 compositor 鎖屏協議）持有。解鎖的正常動作是鎖屏 client 通過認證後呼叫 unlock_and_destroy（協議定義的 request），compositor 收到這個信號才釋放鎖定。

這個責任邊界在自動化測試、VM 演練、遠端操作時最容易出事，因為這些情境常用「殺 process」當「關掉一個東西」的通用手段。殺掉鎖屏 client 跳過了認證，compositor 不會釋放鎖——畫面會卡在失效保護狀態而非回到桌面。

logind 提示與 compositor 鎖的值可以不一致

鎖屏狀態牽涉兩個獨立的層，觸發方向和持有者不同：

loginctl lock-session 走 logind 層觸發鎖屏，鎖屏 client 收到信號後啟動、再向 compositor 取得 session lock。觸發方向是 logind → client → compositor；持有與強制執行方向是 compositor → 畫面。兩者方向相反，正好印證兩層是獨立的。

實測會遇到 LockedHint=no（logind 層說沒鎖）但畫面仍進不去——因為擋住畫面的是 compositor 的 ext-session-lock，跟 logind 提示是兩回事。判斷畫面進不進得去，看 compositor 層，不看 logind 層。

鎖屏 client 非正常結束時的失效保護

鎖屏 client 在持有鎖的狀態下死掉（被 kill、crash），compositor 沒有收到認證通過的信號，只能維持鎖定並顯示失效保護畫面。Hyprland 的失效保護畫面會直接給恢復指令：

1hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'
2hyprctl --instance 0 'dispatch exec hyprlock'

allow_session_lock_restore 允許新的鎖屏 client 接管既有的鎖（否則新 client 會因「已經鎖了」被拒）。接管後是乾淨的鎖屏 prompt，用密碼正常解鎖。

備好 restore 路徑時，殺掉無回應的鎖屏 client 是合理操作——問題不在「殺」、在「以為殺完就回桌面」。restore 的前提是有另一個可操作的 session：另一個 TTY 或 SSH 連線。ext-session-lock 的安全語意允許 compositor 攔截 VT 切換快捷鍵（Ctrl+Alt+Fn），遇到 TTY 切不過去的情況，SSH 是替代救援通道（事先配好 SSH server，見常見故障場景與恢復操作的 GPU hang 段）。

判讀與操作

• 判讀鎖定狀態：loginctl show-session $(loginctl show-user $USER -p Display --value) -p LockedHint 查 logind 層；compositor 層看畫面能否操作。兩層不一致時以 compositor 層為準。
• 正常解鎖：通過鎖屏 client 的認證（密碼 / 指紋），client 呼叫 unlock_and_destroy，compositor 釋放鎖。
• 失效保護恢復：從另一個 TTY 或 SSH 執行 hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1' + hyprctl --instance 0 'dispatch exec hyprlock'，重新拉起鎖屏 prompt 後認證解鎖。
• 自動化流程的代價：啟動鎖屏後，畫面會留在鎖定狀態直到有人通過認證。自動化測試若會觸發鎖屏，要把「需人工解鎖」算進代價。
• 診斷路由：「畫面卡住 / 螢幕鎖了沒」當成一般 Linux 狀態判讀問題（跟判程式活著、判服務歸屬同類）時，見程序、服務與狀態怎麼判——它把「判 session 有沒有被鎖」放進「讀權威狀態、別看畫面猜」的通用診斷紀律裡。
• 延伸閱讀：鎖屏的視覺配置（背景、輸入框、時鐘 label）見配色系統、鎖屏與 GTK 主題的 Hyprlock 段；桌面故障恢復流程見常見故障場景與恢復操作。持鎖的那個 compositor 到底是什麼、還握著哪些系統狀態，見 Compositor 術語卡。

邊界條件

正常認證解鎖（走 unlock_and_destroy）後鎖屏 client 結束，compositor 已回到非鎖定狀態，不觸發失效保護。失效保護只在「持鎖中非正常結束」時出現。

Sway/swaylock 在 client 死掉時沒有畫面上的恢復提示（不像 Hyprland 會印指令），得預先知道走 TTY 或 SSH 執行 restore。「鎖是 compositor 持有、解鎖要認證」是 ext-session-lock 協議層的共通約束；失效保護的具體呈現方式因 compositor 而異。