dwl窗口管理器实战：Wayland平铺、标签与多显示器

dwl 窗口管理器这个名号，在平铺流圈子里属于那种“听说过的人多、真正长期用下去的人少”的类型。它是 X11 时代那套极简平铺思路在 Wayland 上的直接移植，整个工程两三行 C 代码的量级，没有运行时配置文件、没有插件体系、没有图形化设置面板，所有行为写死在一个 config.h 里，想要什么就改源码重新编译。第一次接触的人往往觉得这不可理喻，但用顺了的人基本回不去——标签系统、多显示器支持、纯键盘驱动这几样东西组合起来，窗口管理这件事会变得极有“手感”。

这篇东西打算把 dwl 窗口管理器里真正影响日常使用的十个核心功能挨个拆开讲：标签系统到底和虚拟桌面差在哪、平铺布局的几种算法怎么选、多显示器支持在 Wayland 下有哪些坑、编译期配置的代价和收益、layer-shell 客户端怎么共存、补丁机制怎么维护。面向的读者是已经在用平铺管理器、想从 X11 迁到 Wayland，或者单纯对“几千行代码管好一屏窗口”这件事好奇的人。我不打算写成说明书，说明书官方仓库里有，这里写的是踩过之后才知道的部分。

1. 先把定位讲清楚：dwl 和常见 Wayland 合成器差在哪

很多人第一次装完 dwl 会有点懵——没有设置界面，没有托盘，桌面上干干净净什么都没有，甚至连怎么开第一个终端都要查文档。这不是没做完，而是它本来就不打算做这些。理解这一点，后面十个功能才讲得下去。

1.1 编译期配置这件事，收益和代价分别是什么

dwl 的所有可调项都在一个头文件里：Mod 键是哪个、有九个标签还是五个、边框多宽、焦点色是什么、按哪个键开终端、什么窗口默认浮动。这些不是读进内存再解析的配置，而是在编译阶段直接展开进二进制。改完make一遍，装上去就是新行为。

这么干的好处很实在。启动时没有配置文件解析，没有 YAML 缩进错误，没有“为什么我写了但没生效”这种玄学；运行时也没有配置对象，代码路径短，响应快。坏处同样明显：换一台机器要把 config.h 一起带过去；上游代码更新时，你的改动和它的改动要手动合并；想临时试个新键位，得重新编译一分钟。

我自己的做法是把 config.h 单独放到一个版本库目录里，dwl 源码目录只保留一个软链接指过去，再配一个 Makefile 包装脚本，make之前自动把链接刷新。这样换机器只需要拉两个仓库，不碰任何手写步骤。

注意：不同版本的 dwl 对 wlroots 的 API 依赖非常紧，0.17、0.18、0.19 之间结构体字段和函数签名都动过。升级 wlroots 之前先看源码里的config.mk有没有写死版本区间，别硬上。

1.2 一套最小可用的运行环境长什么样

Wayland 合成器和 X11 窗口管理器最大的区别是：它自己就是显示服务器。所以它需要直接接管 DRM/KMS 输出、libinput 输入设备和会话总线。这意味着几件事必须先满足：内核有对应的显卡驱动、XDG_RUNTIME_DIR已经正确设置且有 0700 权限、当前用户对/dev/dri/card*和/dev/input/*有读权限（通常在video和input组里）。

编译依赖一般是wlroots、wayland、wayland-protocols、libxkbcommon、libinput、pixman。这些在主流发行版的包管理器里都有，麻烦的是 wlroots 版本匹配。你可以先用pkg-config --modversion wlroots看一眼本机版本，再对照 dwl 仓库 README 里写的支持范围，不匹配就先解决这个，别急着编译。

还有一点新手经常忽略：dwl 不能在一个已经跑着的图形会话里直接双击运行。它要用 DRM 后端独占输出，必须从 TTY 启动，或者通过显示管理器拉起。想在现有桌面里试，只能编译时切到嵌套后端，性能和行为都不代表最终效果，只适合看个大概。

2. 标签系统与平铺布局：这套设计的核心在哪

如果只能保留一个功能，绝大多数老用户会选标签系统。它不是“更好用的虚拟桌面”，而是一个完全不同的窗口组织模型，理解了这个模型，后面的布局、多显示器、规则配置全都是自然延伸。

2.1 标签不是虚拟桌面，是多对多关系

传统虚拟桌面里，一个窗口属于且仅属于一个桌面，你要把它从桌面 1 挪到桌面 3，得做一次“移动”操作。dwl 的标签系统换了套逻辑：每个窗口身上挂一个位掩码，代表它被打了哪些标签；当前视图也是一个位掩码。窗口显示与否，取决于这两组位有没有交集。

这个差别带来的实际体验是：一个窗口可以同时出现在多个视图里。比如你把终端同时打上标签 1 和标签 3，切到 1 能看到它，切到 3 还是它。写代码时左边编辑器在标签 1，右边这个终端在标签 3 当参考资料，你不需要复制一份，也不需要来回搬。

操作上对应三个键位族。切换视图是一个键加数字；把当前焦点窗口移到某个标签是加 Shift；切换当前窗口在某个标签上的标记是加 Ctrl。还有一个“查看全部”的组合，把所有打了标签的窗口一次性摊开，适合做总览。

我个人的标签划分是按项目而不是按应用。标签 1 是当天主线任务，标签 2 到 4 是三个并行项目，标签 5 放通讯类，标签 8 是临时区，标签 9 放常驻的参考资料。这么分的原因是：按应用分（浏览器一个、终端一个）会导致频繁在两个视图之间跳，打断思路；按项目分会让你在一个视图里就把一件事做完。

2.2 三种内置布局，以及它们各自适合什么场景

dwl 默认带三种布局，用一个字符符号标识，按切换键循环。

tile是主副栈结构：屏幕左边一块主区，右边一列副栈。主区窗口数量和新窗口进入主区还是副栈由两个参数控制，主区占比也可以实时调。大部分人 90% 的时间都在这个布局里。主区占比的默认值通常设在 0.55 左右，实际用下来，单显示器下这个比例适合编辑器和终端的组合；如果是宽屏，调到 0.6 以上会更舒服。

monocle是把所有窗口铺满整个屏幕，只有焦点窗口在最上层可见。听起来像“一次只能看一个”，但它真正的用途是配合标签做“单窗口专注模式”——你切到某个标签，里面堆了五六个窗口，用 monocle 逐个过一遍，比平铺看着清楚。

float严格说不算布局，它是一个“让当前窗口脱离平铺”的开关。弹出式对话框、视频播放器、图片查看器这类固定尺寸的东西，平铺会很难看，扔进浮动层就对了。

还有一批布局是靠补丁加进来的，比如螺旋式、二分式、网格式。这些不是必需品，我建议新手先只用内置的三种跑两周，确认自己真的缺某种排布方式再打补丁，否则很容易陷入“装了一堆功能但一个都没用熟”的状态。

2.3 浮动窗口与焦点栈的细节

平铺管理器最容易让人困惑的是焦点顺序。dwl 内部维护一个栈，新窗口默认压在栈顶（也就是主区位置），切换焦点是在栈内上下移动，按提升键可以把当前窗口直接拽到栈顶。这套机制的意义在于：你不需要用鼠标点，窗口的层级关系始终是可预测的。

浮动窗口默认不参与平铺计算，但可以配合鼠标修饰键拖动位置和调整大小。这里有个细节值得说：浮动窗口的坐标是相对当前显示器的，如果你把窗口拖到另一个显示器再切回来，位置可能会跳。多显示器场景下我一般不用鼠标拖，直接改规则让特定窗口固定在某块屏上，省事。

提示：判断一个窗口该浮动还是平铺，标准很简单——它的尺寸是否由内容决定。终端、编辑器、浏览器是“我给它多大它就用多大”，平铺；对话框、播放器、取色器是“它自己说了算”，浮动。想不清楚就先平铺，看着别扭再切。

3. 键盘驱动、客户端规则与下拉终端

这套系统的哲学是“手不离主键区”。听起来像极客洁癖，实际用下来会发现它解决的是一个很具体的问题：鼠标定位是二维的，需要视觉确认，而键盘操作是肌肉记忆，不需要看。

3.1 纯键盘工作流的设计逻辑

所有高频操作都是“一个修饰键加一个键”。修饰键默认是 Alt，但绝大多数人会改成 Super（也就是键盘上那个 Windows 键）。改的理由很实际：Alt 在终端和编辑器里被大量占用，冲突太多；Super 在大多数应用里都比较空闲。

为什么是单键而不是组合键前缀？因为组合键前缀需要等待判定的时间窗，按快了会吞键，按慢了会有延迟。单修饰键加单键的组合是即时判定的，没有等待。代价是键位数量有限，所以必须做取舍——哪些操作值得占用一个键位。

我的取舍顺序是：窗口切换和视图切换必须在一级键位；布局调整和比例调整放在二级；剩下的丢给启动器。启动器本身也是键盘驱动的，一个快捷键拉起一个模糊搜索框，输入应用名回车，这比在菜单里点快得多。

键位记忆是个真问题。我的办法是改完 config.h 之后，在注释里给每个键写一行中文说明，然后打印一份贴显示器边上，两周之后就不需要了。别指望靠“我应该记得”硬扛，第一次找不到键会很烦躁。

3.2 客户端规则：让特定窗口自动归位

规则表是标签系统的延伸，但很多人装完就忘了它的存在。它的作用是：某个应用第一次创建窗口时，自动给它打上指定标签、设定浮动状态、指定出现在哪块显示器上。

用一个实际例子说明。视频会议类应用的画中画窗口，尺寸固定、需要置顶、不希望被平铺算法打散，那就给它一条规则：标题匹配某个关键字，设成浮动，扔到标签 8，固定在某块副屏。之后每次开会，这个窗口自己就出现在该在的位置，不用手动折腾。

匹配依据一般是应用的标识名，Wayland 下这个字段比 X11 的应用类名规范得多，通常就是应用自己声明的名字。怎么确认一个窗口的标识名？最简单的办法是先不加规则跑一次，看程序输出的窗口信息，或者用一个能列出当前顶层窗口的小工具抓一下。

规则表是数组，从上往下匹配，第一条命中就停，所以顺序有意义。把最具体的规则放前面，最宽泛的放后面。这个细节文档里往往一笔带过，但顺序写反了会出现“怎么改都不生效”的情况。

3.3 下拉终端：一个键唤出、再按收回

下拉终端是补丁功能，不是内置的。它的实现思路朴素到有点意外：专门划一个标签出来给终端用，按快捷键时切换到那个标签，再按一次切回来。

这个功能的价值在于“随时可用且不打断当前视图”。你正在标签 1 里看文档，需要敲个命令，按一下键终端从顶部滑下来，敲完再按一下它消失，标签 1 的窗口布局一点没变。

实现时要注意两点。一是那个终端必须是常驻的，不能每次唤出都重新启动，否则会话历史和当前目录全丢。二是它最好设成全屏宽度、高度占屏幕三分之一左右，这是实际用下来最顺手的比例，太高会挡住正在看的正文。

注意：下拉终端的标签位不要和日常标签混用。我一开始把它塞在标签 9，结果某天把参考文档也移到 9，唤出终端时文档跟着一起弹出来了。后来改成单独占一个不常用的高位标签，问题消失。

4. 多显示器支持、状态栏与 layer-shell 共存

单屏用户看这一章可能会跳过，但只要插上第二块屏，多显示器的行为差异就会立刻变成日常体验的分水岭。而状态栏和 layer-shell 则决定了这套系统能不能和现代桌面生态里的工具配合。

4.1 多显示器：每块屏有独立的标签和布局

dwl 的多显示器模型是“每个输出独立一套状态”。每块物理屏有自己的当前标签、自己的布局、自己的窗口栈。焦点在哪块屏上，键盘操作就作用于哪块屏。这个设计和“把九宫格扩展到所有屏幕”的方案完全不同，后者的窗口会跨屏流动，前者是彻底隔离。

实际操作上，切换显示器焦点是一组键，把当前窗口扔到相邻显示器是另一组键。这个“扔”的动作很关键——它不改变窗口的标签归属，只是让它出现在另一块屏上。

热插拔是 Wayland 合成器的基本能力，插上屏幕后会自动创建新的输出并分配默认标签。但这里有个坑：输出顺序和物理位置不一定对应。两块屏插上后，系统可能认为左边那块是“输出 A”，而你期望它在右边。修正方式是改输出配置，或者用专门的输出管理工具设置相对位置。

分辨率、刷新率、缩放这些，dwl 本身不管，交给外部的输出配置工具处理。这在设计上是合理的——合成器只管窗口，不管显示参数——但对新手来说是个断层，装完发现分辨率不对会懵一阵。

还有一个实际经验：显示器数量变化时，窗口可能会集中到某一块屏上。这不是 bug，是“原屏幕消失后窗口需要重新归属”的必然结果。如果你经常插拔，建议给关键应用加上规则固定到特定输出，减少混乱。

4.2 状态栏：内置的极简版和外部方案

dwl 带一个内置的极简状态栏，显示标签、当前布局符号和焦点窗口标题。可配置的只有字体、颜色、高度这几项，改法还是老一套——动 config.h 重新编译。

内置栏的优点是零依赖、零额外进程、开销可以忽略。缺点是信息量太少，没有时间、没有电量、没有音量、没有网络状态。想要这些，有两条路。

第一条路是让它往外输出状态文本。dwl 在标签和窗口状态变化时会往标准输出打一行结构化信息，你写个脚本读这行，再拼上时间之类的内容，喂给一个外部栏。这个方式很轻，但需要自己写解析。

第二条路是直接用 layer-shell 类型的外部状态栏。这类栏本身就是独立的 Wayland 客户端，支持模块化配置、图标、点击交互，功能丰富得多。代价是多一个常驻进程，内存占用几十兆。

我自己的选择是后者。理由很实际：状态栏这种东西一旦用惯了显示电量和工作区，砍掉会很难受，而几十兆内存在现代机器上不算什么。但我把它的刷新频率调低了，避免无谓的轮询。

4.3 layer-shell 客户端怎么和窗口管理共存

layer-shell 是 Wayland 里专门给“覆盖层”用的协议：状态栏、壁纸、锁屏、通知、启动器、屏幕键盘都属于这一类。它们不是普通窗口，不参与平铺计算，而是贴在屏幕的某个边缘或者铺在底层。

这套机制带来的好处是：你的状态栏永远不会被平铺算法挤走，壁纸不会被当成一个窗口，通知弹窗不会打乱你的布局。代价是它们和普通窗口的层级关系需要理解一下——覆盖层分几层，从上到下大致是锁屏和通知、状态栏、普通窗口、壁纸。

常见的坑是“状态栏把窗口挤下去了”。因为状态栏声明了独占区域，窗口可用区域会相应缩小。这本来是对的，但如果状态栏高度配置和实际渲染不一致，就会出现窗口底部被切掉一条。排查方法是临时关掉状态栏看是否恢复，能定位就说明是独占区域的问题。

另一个坑是焦点。某些覆盖层客户端会抢键盘焦点，导致你在普通窗口里打字没反应。遇到这种情况先检查是不是刚启动了某个覆盖层程序，逐个排除。

5. 从零编译到跑起来的完整实操

前面讲的都是概念，这一章给一套可以照着敲的流程。我按“最小可用”的标准来写，能跑起来、能开终端、能切标签就算成功，剩下的慢慢加。

5.1 依赖检查与编译

先确认 wlroots 版本，这一步不能跳：

pkg-config --modversion wlroots

拿到版本号后对照源码仓库里的说明，落在支持区间内再往下走。依赖装齐：

# 以 Debian 系为例，包名按本机实际情况调整 sudo apt install build-essential pkg-config \ libwlroots-dev libwayland-dev wayland-protocols \ libxkbcommon-dev libinput-dev libpixman-1-dev

然后拉源码、编译：

git clone <仓库地址> dwl cd dwl make clean make

编译报错九成集中在 wlroots 版本上，错误信息里通常会出现某个结构体成员找不到或者函数参数数量不对。这种情况不要硬改，先确认版本，实在不行就切到对应版本的分支。

make通过之后不要急着make install，先用./dwl -v之类的方式确认二进制能正常加载动态库。

5.2 config.h 里真正需要改的那几项

一份默认配置能跑，但不好用。我列一下必改项，附上理由。

第一项是修饰键。默认的 Alt 冲突太多，改成 Super：

#define MODKEY WLR_MODIFIER_LOGO

第二项是标签数量和名字。默认九个数字标签，如果你的用法是“按项目分”，改成有语义的名字会更容易记：

static const char *tags[] = { "main", "proj-a", "proj-b", "chat", "ref", "tmp" };

注意改短了之后，按键绑定里的标签位掩码也要同步改，不然按了没反应。

第三项是焦点边框颜色。默认配色在多窗口下辨识度不够，换成对比度更高的：

static const float focuscolor[] = COLOR(0x7aa2f7ff); static const float bordercolor[] = COLOR(0x2a2e3aff);

第四项是规则表。至少给浏览器和视频播放器各加一条，前者固定标签，后者设成浮动：

static const Rule rules[] = { /* app_id, title, tags mask, isfloating, monitor */ { "firefox", NULL, 1 << 1, 0, -1 }, { NULL, "Picture-in-Picture", 0, 1, -1 }, };

第五项是开终端的键位。默认绑定的终端不一定是你装的，改成自己实际在用的那个：

{ MODKEY, XKB_KEY_Return, spawn, SHCMD("foot") },

改完make && sudo make install，装到系统路径下。

5.3 启动方式和自启客户端

从 TTY 启动最直接。在 shell 的启动脚本里加一段判断，只有当前在第一个 TTY 且没有图形会话时才拉起：

if [ -z "$WAYLAND_DISPLAY" ] && [ "$(tty)" = "/dev/tty1" ]; then exec dbus-run-session dwl fi

外面套一层会话总线是为了让通知、输入法等依赖 D-Bus 的程序能正常工作。少了这一层，很多程序会静默失效，而且不会有明显报错，很难查。

自启客户端有两种做法。一种是打补丁，让 dwl 在启动时按列表拉起几个程序；另一种是写个启动脚本，先拉起状态栏、壁纸、输入法，最后exec dwl。我更倾向后者，因为脚本好读好改，出问题容易定位。

#!/bin/sh swaybg -i ~/wallpaper.png & waybar & fcitx5 -d & exec dwl

顺序有讲究：壁纸和状态栏要在合成器起来之前或同时启动，因为它们需要连接 Wayland 显示；输入法可以稍后，但最好也别拖太久。

提示：第一次启动前把配置文件备份一份。dwl 出问题最常见的表现是黑屏或者直接退出，没有报错窗口，只能从 TTY 的日志里看原因，提前留好退路能省很多时间。

6. 常见问题与排查实录

这一章按“症状、可能原因、处理方式”来组织。都是我自己或者身边的人实际遇到过的，不是从文档里抄的。

6.1 启动阶段的典型故障

启动后黑屏，什么都不显示。这个最常见的原因是输出没被正确识别。先看日志里有没有输出相关的报错，再看显卡驱动是否加载。如果用的是比较新的显卡，内核驱动版本可能不够，需要更新内核或者固件。

启动后闪一下就退回 TTY。多半是某个自启客户端崩溃导致整个会话退出，或者XDG_RUNTIME_DIR权限不对。先把自启脚本清空，只留exec dwl，能起来再逐个加回去。

键盘完全没反应。检查当前用户是否在输入设备组里，有没有权限读/dev/input/event*。另一个可能是键盘布局没配置，虽然按键有事件但映射不到字符。

6.2 日常使用中的周边问题

输入法打不出中文。这是 Wayland 下最经典的问题之一。需要确认三件事：输入法本身跑的是 Wayland 前端而不是 X11 前端；环境变量里指定了正确的输入法模块；合成器支持输入法协议。三者缺一不可，而且任何一个不对都不会有明确报错。排查办法是先用一个最简单的应用试，比如终端里能不能输入中文，能就说明输入法链路通了，问题在具体应用。

截图工具用不了。Wayland 下的截图依赖专门的协议，需要合成器实现。如果截图工具报“不支持”，先确认它是不是 Wayland 原生版本，X11 版本的工具在 Wayland 下截不到东西。

剪贴板跨应用不生效。同样是协议支持的问题。另外要注意：剪贴板管理器本身也是一个客户端，它需要在合成器启动后才能工作，放太早会拿不到内容。

窗口标题不更新。有些应用不主动上报标题变化，导致状态栏显示的还是旧名字。这种情况一般无解，除非应用自己修。

光标主题不对或者光标消失。Wayland 下光标由合成器和客户端共同决定，环境变量里设置光标主题和大小，两边都要认。设了没生效的话，检查变量名是否写对，这类变量名很容易拼错。

6.3 几条不太好归类但很值钱的经验

第一条：日志永远是你的朋友。dwl 的输出直接打在启动它的那个 TTY 上，出问题时别急着杀进程，先切回去看最后几十行，八成有线索。

第二条：改动要小步。一次只改一个键位或者一条规则，编译、测试、确认，再做下一个。一口气改二十处然后发现不生效，排查成本会翻好几倍。

第三条：保留一份能跑的配置。在把玩新补丁之前，把当前 config.h 复制一份加日期后缀。补丁冲突搞乱了，五分钟就能退回去，不至于从头再来。

第四条：别迷信“功能越多越好”。我见过有人一上来打了十几个补丁，结果键位冲突、行为互相干扰，用了一周就放弃了。先用原生功能跑一个月，你会很清楚地知道自己缺什么，那时候再打补丁目标明确得多。

7. 补丁机制与长期维护的取舍

最后一个话题看起来不性感，但它决定了你能不能长期用下去。极简方案的真正门槛不在于第一次配置，而在于半年后你想升级时，发现改动已经和上游拧成一团。

7.1 补丁要怎么挑，怎么打

补丁本质上是 diff 文件，描述“在哪些文件的哪些行插入或修改什么”。打补丁就是把这个差异应用上去。理想情况下一条命令搞定，实际情况经常是上下文对不上，需要手动改。

挑选原则我总结成三条。第一，只打解决真实痛点的补丁，不要因为“看起来很强”就上。第二，优先选维护活跃的，也就是还在跟着上游代码更新的那些，陈年补丁在新版本上大概率打不上。第三，一次只打一个，打完编译测试，通过再打下一下。

打补丁的流程一般是先试应用，看有没有冲突：

patch -p1 --dry-run < some-feature.patch

--dry-run只检查不修改，很关键。确认没冲突再实际执行。有冲突的话，.rej文件里会记录失败的片段，手动对照当前源码改。

7.2 升级上游代码时怎么不把自己坑死

这是长期使用最痛的一环。上游改了核心逻辑，你的 config.h 和补丁都要跟着动。如果没有版本管理，这一步基本等于重来。

我的做法是把整个源码目录纳入版本控制，上游仓库设成一个远程，自己的改动在一个分支上。上游更新时先拉下来，然后把自己的分支 rebase 上去，冲突集中处理一次。

rebase 冲突主要集中在两处：config.h（因为改动最多）和补丁触及的核心文件。config.h 的冲突好处理，因为它是纯数据，逐段对照就行。核心文件的冲突麻烦一些，需要理解补丁想做什么，再在新代码里找对应的位置。

还有一个降低维护成本的办法：把能用外部程序解决的需求，尽量不用补丁。比如状态栏信息，用外部栏而不是改源码；比如快捷键，能在 config.h 里加就别改逻辑。补丁只留给真正需要改行为的场景，比如下拉终端这种。

注意：升级前务必先提交当前状态。rebase 到一半发现搞不定想退回去，如果没有提交点，就只能靠记忆恢复，那是最难受的处境。

我个人在实际操作中的体会是，这套东西的价值不在于功能多，而在于每一个行为你都能追到源码里的某一行。用久了会有一种奇怪的安全感——出任何问题都不需要等别人修，打开编辑器就能改。代价是你得接受它不会替你兜底，配置错了就是错了，没有“恢复默认设置”这个按钮。想清楚这一点再入坑，会少很多挫败感。