依云's Blog

使用24寸4k屏幕作为主屏的时候很简单，设置 scale 为 2 就好了。但是，当 2 嫌太大、1 嫌太小的时候，问题就来了。比如我希望使用 120dpi，把 scale 设置为 1.25 可好？

而这才是理想的效果：

看不出来差别？放大八倍，你看差别多明显：

正常 120dpi 渲染出来的文字边缘清晰犀利，次像素平滑左红右蓝。再看看 scale=1.25 的文字，线条经常糊掉，次像素平滑效果几乎完全被抹掉。实际看上去的效果就是跟透明麿沙玻璃看屏幕似的，线条边缘总是有点糊糊的感觉，1080p 的屏幕被降级成了 720p 似的。

之所以出现这样的情况，是因为 Wayland 只支持整数倍缩放。因为，Wayland 混成器不能告诉客户端你得把窗口给画成 1.25 倍的，而客户端也无法告诉混成器我这个图像画的是 1.25 倍。所以，混成器只好告诉客户端你给我画个 2 倍的图像吧。混成器拿到图像之后再缩小 0.625 倍，自然有些逻辑像素就不能对应到单个的物理像素上去了。

所以，我还是设置 scale=1，不要混成器帮我去缩放。我自己通过另外的办法告诉客户端把字写大点儿。图标之类的就顾不上啦，反而大点小点都还能看。比如我要 1.25 倍大小的文字，就这样做：

• GTK 3：在 dconf 里设置org.gnome.desktop.interface.text-scaling-factor=1.25就好了。最开始的截图就是 dconf-editor 里这一项配置。
• Qt：设置环境变量 QT_WAYLAND_FORCE_DPI=120。
• Telegram：除了上边这个环境变量外，额外地在它自己的设置里设置 150% 的缩放（Telegram 的字偏小所以要设置得大一些）。设置环境变量是为了 fcitx5。
• waybar：config 文件中设置 height，style.css 中设置 font-size。
• Xwayland：和 X11 下的 HiDPI 设置差不多的。比如 GTK 2 设置 Xresources Xft.dpi: 120 就好了。

我遇到的差不多就这些了。没办法，Linux 就是这么乱 QAQ。不过虽然 Wayland 协议不支持，好歹还有绕过的办法。

我又来更新我的 Wayfire 迁移进展啦～

我写了一个 taskmaid 工具，使用 wlr foreign toplevel management 扩展来提供窗口管理相关功能。程序自己作为 daemon 随 wayfire 启动运行，通过 D-Bus 提供接口供别的程序使用。你问我为什么不直接每个需要的程序直接使用 Wayland 协议？因为用起来麻烦呀。Wayland 提供信息的方式是一组一组的事件，也并没有高层次的库，处理起来只能一堆回调怼上去，相当不顺手。

它最主要的功能就是在 waybar 上标题当前窗口的标题啦。顺便加上了中键关闭和显示 app-id 的功能。应用程序图标因为没有办法准确匹配（比如火狐 nightly 版本的 app-id 也是 firefox），所以没有做。

其次是获取当前活动窗口所在的显示器接口名称。我使用这个名称来判断我是不是位于 E-ink 屏幕上，并为终端、Vim、skim、mutt 等工具使用专门适配过的亮色主题。这个方案比之前在 X11 下使用当前鼠标坐标来判断要灵活一些。当然更灵活的方案是匹配显示器的名称啦，这个数据 Wayfire 的 Wayland 协议里是有提供的，有需要的话我再做。Wayland 并没有一个协议来获取当前鼠标或者键盘焦点所在的显示器信息，所以我只好用窗口管理协议来跟踪活动的窗口了。

顺便还做了个 lswin 工具，列出打开的窗口信息。工作区太多啦，我又喜欢最大化，有时候会有窗口忘了关。甚至偶尔我还会不小心把窗口最小化了，然后没有办法给恢复回来……如果以后还经常出现这种情况，我再给 taskmaid 加一个恢复最小化窗口的功能好了。

除了使用 taskmaid 显示标题之外，我还加了个显示 AQI 的小脚本。以及之前忘记加网速指示器了，现在也加回来了。不得不说 waybar 比 Awesome 的那个顶栏要好配置得多。不仅不限语言，而且不是非得用定时器，可以在信息变动的时候及时更新信息，没变动就不浪费资源获取重复的信息了。我的 waybar 配置都在这里。

我给 Wayfire 发了一个 pull request，添加了最基础的快捷键禁制器的支持，可以在 spicy 等软件中屏蔽 Wayfire 自己的快捷键了，大大方便了我对 Wayfire 和 Sway 的测试。当然也可以用于 VNC 啦。不过并没有像 Sway 那样加选项、支持主动禁用快捷键等功能，短期内我也不太可能会去加这个。原本我是想着在 Wayfire 里再跑一个 Wayfire 或者 Sway 啥的，但考虑到配置方面的问题，还是拿虚拟机隔离了比较好。

最新的 Wayfire 版本已经支持切换到之前的工作区啦～

桌面通知程序 mako，之前遇到两个问题。一是通知经常是糊的，没有适配 HiDPI 屏幕，而鼠标指针则一直都是又糊又大。我给修了，虽然我其实有点不知道我是怎么修好的……总之是整理了一下代码，为了减少调试日志而减少了与 Wayland 混成器的通讯，也变得更高效了。会记住上次显示使用的缩放倍率，所以不会像之前那样一出来是糊的、下一刻才会变清晰了。在 Wayland 协议里，客户端可以获知有哪些显示器、大小和缩放倍率如何，但是客户端并不能提前知道自己将会显示在哪个显示器上（倒是能够指定显示在哪个显示器上），只有显示出来之后才知道，然后做调整后再更新一下……

另一个问题是，在 Wayfire 下 mako 在全屏时不会显示通知，会被盖住。设置 layer=overlay 之后倒是能在全屏时显示通知了，但是它也会在 swaylock 锁屏界面上显示……后来了解到 mako 有模式这么个特性，我就在锁屏的时候切换到专为锁屏设置的模式下，解锁之后再切回来。反正锁屏是一句命令，自己拿脚本包一下就好了。

最近新的桌面环境稳定下来了，倒是没有再遇到更多的 bug 了。Spicy 会在里边的虚拟机跑特效动画时经常报个「Gdk-Message: Error flushing display: 资源暂时不可用」错误然后退出，我给它用 try_until_success 包了一下倒是问题不大。我也发现了不光是 Wireshark，也有 GTK 程序弹出菜单会显示在错误的位置。

那么就酱～

这几天完成了一个很重要的功能：我让 Xwayland 支持 HiDPI 了！

实际上让 Xwayland 支持 HiDPI 的补丁早就有了，但是我当时尝试的时候补丁并不能很好地应用，我手动修了修，不明不白地应用上之后，并没有能够正常使用。现象是，DPI 是对了，但是窗口大小会不断地缩为原来的四分之一（长宽都减半），全屏时也只占左上角的四分之一。

这几天我给 xorg-xwayland 打上了新版补丁，然后在一番理解之后，给 wlroots 写好了相应的补丁，现在 Xwayland 终于也可以看清晰了！

这两个补丁，xwayland 那边是通过一个 X 窗口属性来设置缩放倍数，然后 xwayland 会告诉混成器自己的窗口使用了对应的缩放倍数，这样混成器就不会当它不支持缩放、强行给拉伸一下了。当然还有输入坐标的转换之类的。缩放倍数为 2 时，X 客户端会看到之前两倍的显示大小，并且 X 使用的坐标是 Wayland 这边的两倍，所以 Wayland 的输入事件从 X 服务器传给 X 客户端的时候需要乘以 2。

混成器这边，需要了解客户端传过来的 X 坐标和 Wayland 坐标不再相同，需要进行相应的转换。没有进行转换的结果就是，客户端告诉混成器说自己是 1024x1024 的窗口大小，然后实际上创建出来是 512x512 的。混成器再告诉客户端你现在只有这么大，然后客户端说好，我调整一下。于是又变小了……

两个补丁打上之后，由于头文件有变化，混成器可能需要重新编译一遍。然后按 X 的方式设置 HiDPI，比如设置 Xft.dpi: 192 或者 winecfg 里设置 dpi 为 192。如果有运行于 Xwayland 的 GTK 3 程序，也要设置 GDK_SCALE=2 GDK_DPI_SCALE=0.5。然后执行以下命令设置 X 属性，让 Xwayland 做相应调整：

xprop -root -format _XWAYLAND_GLOBAL_OUTPUT_SCALE 32c -set _XWAYLAND_GLOBAL_OUTPUT_SCALE 2

接下来就能愉快地 wine 和 gimp 啦～

这几天做的另一个比较大的动作是配置好了 waybar。我也不知道这个组件叫什么好，很多地方都叫面板（panel），i3 / sway 那边直接叫 bar。它现在经常出现在屏幕顶部所以我也有时叫它顶栏。总之就是显示窗口信息、系统托盘和状态指示器啥的那一条。

我是从它自带的配置文件修改的，但是风格给完全改掉了。原本的风格是一块一块的彩色背景的字，我嫌太过显眼，经过一番调整之后，给改成了黑底上的彩色字，跟我原来的 Awesome 差不多，也和我显示器的黑边挺配的。指示器的放置也是差不多的。十分遗憾的是并没有合适的窗口列表小部件可用。它自带的那个 wlr/taskbar 会把所有工作区的窗口全部显示出来，很挤。而且不知道为什么，一旦加上它之后就最小要占用 34px 的高度，太占空间了，所以作罢。我打算以后自己实现一个，现在就拿正在播放的媒体凑一下吧。它现在长这样：

左边就是使用 playerctl 做的媒体信息。左键可暂停播放，滚轮切歌。字的颜色是和窗口边框匹配的。

中边留着给窗口标题。

右边依次是：

• idle 禁制器。点一下眼睛亮起来，禁用无活动时自动休眠。
• CPU 和 load 信息。
• CPU 温度。太高了会变红。
• 内存使用率。
• 电池信息。充满电又插着电源线，它就隐藏起来了。预期充电或者使用的时候图标会出现，并且可以看到剩余时间。如果在放电并且电量低，应该会变红并且闪烁。这设定跟我 Awesome 的那个一样，不知道等到什么时候才能用上，到时候才能看到效果了。
• 音量。左键单击是切换静音，滚轮调节音量。图标会显示设备类型（我这里有内建、HDMI（实际上是走的 DP）、蓝牙三种）。麦克风静音的时候也会显示图标。
• 系统托盘。它终于可以在多个屏幕上同时显示啦～
• 时钟。

我最终还是用上了那个包名为「otf-font-awesome」的图标字体。

waybar 比 Awesome 的 bar 好配置多了。很方便使用外部程序来定义。也不一定要用定时器。程序可以一直跑着，一行一条状态更新，就不需要在「更新不及时」和「更新太频繁消耗资源、干扰调试」之间抉择了。

我把 wayfire、waybar 以及其它一些东西的配置文件上传到 GitHub dotconfig 仓库了。XDG 标准路径挺好的。

还有一些小的更新——

壁纸我使用了 swaybg，因为它支持不同显示器使用不同的壁纸，这样我的 e-ink 墨水屏就可以独享纯白壁纸了～或者什么时候我专门找张合适的黑白壁纸也挺好的。

fcitx5 输入条的文字 padding 太大。鉴于我现在日常使用 Wayland 了，我改了我这个主题，适配 Wayland。X 那边也没有太难看。

fcitx5-paste-primary 已经添加了 Wayland 支持，虽然实现很不优雅……

看图软件，使用 imv（同时支持 Wayland 和 X）取代了 sxiv。许多图片要预览的话，thunar 或者 geeqie 也挺好的。

以及一些已经报告的 bug：

• xfce4-appfinder 无法启动 Xwayland 程序，因为它把 DISPLAY 环境变量传错了。
• flameshot 多显示器时，只能编辑左上角部分内容。
• mako 全屏时不能显示通知。设置 layer=overlay 的话会显示在锁屏（swaylock）之上。

还有一些未报告和未调查清楚的 bug，等事情明了之后我再更新啦～

这几天又解决了一些问题，记一下。

Wayfire 部分：

• 部分按键绑定无效的问题，Super+数字键无效是因为这个是 git 版本才有的。PrintScreen 无效是因为需要写成KEY_SYSRQ……
• 窗口标题的问题。显示中文的 pr 已经提交。也把 scale 插件的问题一起修了。
• 要不显示标题栏也很好办，首先 preferred_decoration_mode = server 让窗口们都用 wayfire 画的装饰，然后设置 height = 0 这样就看不到标题栏啦（窗口边框还留着；连边框都不想要的话可以不加载这个插件就好了）。
• lightdm 启动不了 wayfire 的问题，在 ~/.xprofile 里 sleep 1 就好了。相关 issue：Missing some input devices in wayland session · Issue #63 · canonical/lightdm。
• 嗯，lightdm 是会给 Wayland 会话 source ~/.xprofile 的。所以在里边判断 XDG_SESSION_TYPE 环境变量然后做相应的处理就好了。另外 sddm 是会 source ~/.profile 的。
• invert 和 zoom 插件只支持一个显示器的问题，没有再次复现。可能是 git 版修了吧。
• 挂起之后恢复，没键盘鼠标的问题大概也好了？今天我只遇到过一次没键盘，重新插了一下……
• resize 调整窗口时保持比例（比如用于 scrcpy）。我已经在自己的 fork 中加入这个功能。
• 锁屏使用 swaylock。不过它只锁屏并不会关显示器，所以我又写了个 xset dpms force off 的等价程序。
• HiDPI 下 Xwayland 窗口是糊的。通过改变插值算法（默认的 GL_LINEAR -> GL_NEAREST）来缓解。sway 默认就支持这个。这个 nearest 算法在整数倍放大时，会不那么糊，不过颗粒感会很明显（就是把显示器分辨率给降回去啦）。
• 哦，还有个 git 版本的新问题：slurp 或 swaylock 在运行时，会消耗不少 CPU。我发现是由于 wayfire 一直在发送 configure 事件造成不断地重绘，已经给补上并提交 pr 了。

我的 Wayfire fork 位于 https://github.com/lilydjwg/wayfire/tree/lilydjwg，里边有什么请自行看提交历史。不过要注意的是，这个分支我可能会 push -f 以清理历史。

应用程序部分：

• flameshot 需要设置 XDG_CURRENT_DESKTOP=sway 才能工作，然而在多显示器的时候只会给用户编辑左上角的部分，还是没法用。于是我用回传统的「选择+截图」组合了，只不过在 Wayland 下是 slurp + grim 这个组合。
• wl-paste 和 xsel 不同步的问题，是由于 wlroots Xwayland 在窗口没有焦点时，被禁止与 Wayland 部分同步剪贴板。
• 我装好 xdg-desktop-portal{,-wlr}，设置好 XDG_CURRENT_DESKTOP 环境变量，然后重置了一下 obs-studio 的配置文件之后，它能工作了。不过只能录整个屏幕，不能按窗口录啦（由于更容易意外录到别的内容，反而不那么安全了）。

然后是剩下的问题：

• spicy 无法捕获键盘是因为 wayfire 没有实现那个协议。有空我去 patch 一下好了。
• 火狐还是不能录屏。听说是协议有更新火狐还没跟上？
• wireshark 的菜单会显示在屏幕最右边。
• mako 的通知文字经常是糊的，reload 一下什么的可能会好。也遇到过它不显示，reload 一下又好了的情况。
• GTK 3 程序的右键菜单，上下会多出一部分内边距并被加上的圆角。圆角我还能忍，但多这么一部分不能选中就很难看了，然后火狐的多级菜单还没把这个考虑进去，没对齐各级菜单……

解决这各种问题挺累的，我就不仔细核查和整理了。本文只是个记录，把已经完成的事项从我的 TODO 列表转存到博客而已啦=w=

我在上一篇说到，Wayland 下再也不会遇到撕裂了。后来群友说，这是 Intel 的 modesetting 驱动特有的问题。所以我又重新比较了一下。为了让事实说话，而不是靠很容易有偏见的主观感受，我使用 Sony Xperia XZ2 Compact 手机的「慢动作」功能，以 960fps 录制了不同情况下，火狐滚动同一页面的效果。不过视频我就不放了，上传费时又占地方。

首先是我长期使用的组合：X11 + Intel 集成显卡 + modesetting DDX，窗口管理器是 Awesome 3.5.9，混成器是 picom。这种情况下有非常严重的斜线撕裂，在画面内容变化大的时候（如无过渡切桌面、视频镜头转换、大幅度滚动页面）必现。撕裂的样子如下（「慢动作」的分辨率有限，亮度低是预期现象）：

可以很清楚地看到，截图中的页面是由两帧的内容拼接而成的。而且左下的是后一帧，右上的是前一帧，我不知道为什么会是这样子。我记得以前它不会撕这么大条斜线的啊，是斜-水平-斜的样子。反正都很难受就是了。我以前以为这种撕裂是时不时出现的，但多次「慢动作」慢放表明，它发生的频繁度大大超出了我之前的感受。

这个组合还有个问题是：外接显示器时，鼠标会跟着画面的更新而闪烁。画面更新越多越频繁，它闪烁得越快，而且和更新的区域也有关系。因为眼睛总跟着鼠标跑，所以即使它大部分时候不影响定位，但对主观感受的伤害应该也挺大的。

然后 Wayland + Intel 集成显卡，混成器是 Wayfire。完全观察不到撕裂。鼠标光标也很稳定不闪。

X11 + Nvidia 独立显卡 + 官方闭源驱动。还是 Awesome + picom 的组合，输出还是经过 Intel 显卡。也完全观察不到撕裂。不过有个更严重的问题——我的外接显示器每十来秒会黑屏几秒。听说把显示器关掉重开就可以解决，不过我无意使用这个方案，就不理它了。除了我之前提到的容易崩溃之外（其实我也不知道现在它还崩不崩），这显卡不支持视频硬件加速。这意味着我根本没办法看 4k 视频。PS: 火狐的 WebRender 能正常自行启用。

X11 + Intel 集成显卡 + Nvidia PRIME Offloading。我只是好奇地试一试这个方案啦。以前这个方案里火狐没办法启用图形加速，只能用「basic」渲染器来着。现在火狐有了 Software WebRender，倒是也能比较好地跑起来了。依旧会撕裂，好像比用 Intel 显卡要好那么一点点？

然后对比一下水族馆的图形性能数据：

• X11 + Intel 显卡，30fps 左右。
• Wayland + Intel 显卡：接近 60fps。
• X11 + Nvidia 显卡：30-40ftps。
• X11 + PRIME，这个比较令我意外，竟然也在 30fps 上下。要知道这个是纯 CPU 实现的，没有 GPU 加速的呀。

其实 WebGL 我用得不多啦（Google 地图更常卡在网络 I/O 上而不是渲染上）。更多的是播放在线（YouTube）视频啦。

• X11 + Intel 显卡，1080p 60fps，GPU 用满，丢帧三分之一！4k 60fps 也差不多。原来重点不是分辨率（反正 GPU 的解码能力还没用满），重点是视频的帧率啊。
• Wayland + Intel 显卡，4k 60fps 都不怎么丢帧，更不说其它了。GPU 图形计算用到一半左右。
• 没有更多方案了。我这 CPU，软件解 4k 会卡成 PPT 的。

综上，Wayland 的表现是最好的！好吧虽然遇到了挺多问题的，不过我大概都能修或者绕过。虽然撕裂不全是 X11 的错，但是确实有客观证据证明它体验不好，不是 Wayfire 的特效太绚烂太怀旧让我偏心了～

前天得知 wayfire 能够直接在 X Window 下运行之后，我就尝试了一下。很好，能跑。虽然不能捕获键盘，从而与外边窗口管理器重复的快捷键无法使用，但至少它的鼠标光标位置是对的，能够用来测试。我在 QEMU 里跑过 KDE Wayland、sway 和 wayfire，无一例外鼠标位置不对。KDE 里是缩放倍数设为 2 之后，鼠标的实际坐标会翻倍。后两者基于 wlroots 的，鼠标的实际坐标位于显示的光标上方几十像素处。总之没法用。

在 X Window 里粗略地配置了一下 wayfire 之后，我就想实际在外边跑跑看。结果被惊艳到了，感觉就像年轻了24岁一样！

优势

尝试几次之后，我终于把 wayfire 跑起来了。

首先是火狐图形性能翻倍！

我打开火狐，跑了一下 WebGL 水族馆（微软的 FishGL 没啦）。接近 60fps，是我在 X Window 下跑的两倍有余！再试试 YouTube 的 4K 视频，竟然几乎不掉帧！我的电脑的性能原来这么好的吗……在 X Window 下，火狐播放这 4K 视频，会占满 GPU，并且 CPU 也几乎用满，丢掉约十分之一的帧。而在 Wayland 下竟然只用了一半的 GPU，CPU 用量也不怎么高。而且操作起来很流畅，右键菜单一点就出来，鼠标划过菜单项，高亮也跟得很紧。

画面再也不撕裂啦！

一直以来，我切换窗口、播放视频、快速滚动窗口内容的时候，时不时能见到画面撕裂。一般是在中间附近，一道水平接着倾斜接着再水平的裂痕会一闪而过，其上和其下是两帧不同的内容。读过 xplain 以及 Wayland Book，我知道这是由于 X Window 服务端与客户端之间并不同步，显示画面时，缓冲区里有啥画啥，并不在乎客户端有没有画完，导致相邻的两帧拼接在了一起。而 Wayland 会使用双重缓冲，客户端在缓冲区里画好了，才告诉混成器这一帧画好了、可以显示出去了。而在画好之前就显示上一次提交的缓冲区内容，所以永远不会出现画一半的情况。

我的光标也不再闪烁啦！

我也不知道为啥，我在 X Window 下，特别是接外接显示器的屋里，鼠标光标会像遥远的星星一样闪啊闪的，有时候闪得甚至影响我操作。我用的 picom 混成器的选项我改来改去，不光没能解决这个问题，反而是搞得它时不时崩溃一下了。我也不知道这是怎么回事，按理说鼠标光标由硬件绘制的，不应该时有时无啊。而在 wayfire 里，光标一直很稳定，从来不闪烁。我是返回到 X Window 下才注意到这一点的。

特效！

尝试 wayfire 的一大原因是我看中了它的特效。当年我初入 Linux 的时候，就挺喜欢 compiz 的特效的，只是后来因为性能问题才转到 Awesome 的。wayfire 有好多我当年常用的特效，果冻、火焰、立方体、展览，还有那个翻页一样的切换效果叫啥来着。没有纸飞机倒是有点可惜。

其它的 Wayland 混成器，KDE 我已经尝试过了，虽然是 X Window 版本，但功能应该是一致的。同样 sway 的对应 X Window 版本 i3 我也尝试过了。结论是，我并不是很在意平铺，但是我很在意键盘操控性。wayfire 也有较为丰富的键盘操作设置，应该也可以通过插件来扩展。

已解决的问题

虽然有上边这些优势，我还是回到 Awesome 来了，因为还有不少问题和需要配置的地方呢。此节记录一下我已经解决的问题。

• GVim。因为 GVim 使用的是 GTK，所以改一改让它支持 Wayland 并没有很难。我改好的版本在我的 vim fork 的 wayland 分支上。目前还缺少两个重要功能：终端里的剪贴板，以及 +clientserver。
• mpv 是糊的。研究发现这是因为我加了no-hidpi-window-scale参数。它是为了解决 X Window HiDPI 下窗口过大的问题，但到了 Wayland 下使用它就会导致并不进行 HiDPI 缩放了。
• 窗口焦点不会跟随鼠标。这是在平铺式窗口管理器里使用很广泛的特性。wayfire-plugins-extra 里有个 follow-mouse 插件可以实现这个。
• GTK 的鼠标主题、禁用动画设置等不生效。原来在 Wayland 下 GTK 不读取~/.config/gtk-3.0/settings.ini，可以使用 dconf-editor 去编辑 org.gnome.desktop.interface 下的选项。
• xfce4-notifyd 的通知会被当成普通窗口，置于屏幕中间并且有标题栏。有一个 fork 修复了此问题，不过我还是决定使用更轻量的 mako（不是 Python 的那个模板引擎哦）。
• Xwayland 跑 PRIME offloading 时，Minecraft 的画面会来回抖动。于是只好放弃 NVidia 显卡改成 Intel 显卡了（反正自从我买了 4K 显示器之后就都跑不动了 QAQ）。
• fcitx5
  • GTK 中，在输入编码的时候，按一次键闪烁一下。csslayer 说是不这样做就无法移动窗口。于是我改了一下代码，选择移不动。反正也只有在屏幕边缘的时候才需要移动。Qt 那边这个问题倒是不大，因为 fcitx5-qt 总是在应用程序的窗口范围内绘制候选词窗口，能够判断什么时候需要移动，所以只是在屏幕边缘的时候闪一闪。
  • Qt 中（就是 Telegram 啦），在窗口下方输入的时候候选词窗口会悬在文本上空。我改了一下代码，现在能够准确定位到文本的上方紧贴着了。代码已经 pr。
  • fcitx5-configtool 不显示部分图标。把GNOME_DESKTOP_SESSION_ID=0环境变量加上就好了。这个环境变量莫名其妙地解决了不少问题呢。

剩下的问题

我暂时还是以 Awesome 为主，因为还有很多问题有待解决：

• Vim 不支持剪贴板、clientserver 特性。我打算通过另外的方式实现。工作量有些大。
• SPICE 客户端 spicy 无法捕获键盘，造成虚拟机里无法使用与外边相同的快捷键。
• LightDM 启动 wayfire 会话时会立即退出，而实际上 wayfire 是已经启动了的。各种日志里均没有找到任何有用的信息。
• wl-paste 获取的剪贴板内容与 Xwayland 的并不同步。似乎大部分程序都支持两种剪贴板协议，但是 wl-paste 和 Xwayland 各支持其中之一？
• Xwayland 不支持 HiDPI。有个补丁，但是会造成窗口一直缩小再缩小。
• fcitx5
  • 候选词的内边距有些大。有空再调了。
  • fcitx5-paste-primary 不支持 Wayland。有空再加了。
• wayfire
  • 窗口标题不支持中文。我倒是打算给 wayfire 加个不显示标题栏的选项。
  • 的 fast switch（真的很快）会导致全屏窗口取消全屏。
  • 似乎不支持触摸板拖拽的时候中断一下。应该很好修补吧？
  • 只能切换到本工作区的上一个窗口，不能跨工作区
  • invert 和 zoom 插件只支持某一个显示器。前者我用不到，但后者应该还有些用处的。
  • 设置的 Super+数字键 切换工作区无效。
  • 我还没想好我那些环境变量去哪里设置比较好。~/.xprofile没啦，~/.pam_enviroment我也不想用。在考虑使用 systemd 那个功能，或者我自己 wrapper 一下 wayfire。

缺憾

• 使用 libinput 取代了 synpatics，非常好用的画圈滚动（一直画、一直滚）没了。

结语

还有挺多东西要配置的。锁屏啦，壁纸啦，还有未发现的问题啦，等等。慢慢来吧。Wayland 真的挺顺滑的。

对了，有个有意思视频给大家看一下。

这是我还没运行通知守护进程时，火狐发出的通知窗口，不知道为什么被反复创建和销毁。

缘起

我的蓝牙耳机有简单的多媒体按键：上一曲、下一曲、播放、暂停。这几个按键在 Android 手机上是开箱即用的，然而在 Arch Linux 上，尤其是我的 Awesome 桌面环境上，并不那么自动。

其实按键事件都能收到的啦。可以收到 XF86AudioPrev, XF86AudioNext, XF86AudioPlay, XF86AudioPause 这么几个按键。给它们绑定热键，去调用 MPRIS 就好了。我使用的是 playerctl 工具。mpv 的 MPRIS 支持用的是 mpv-mpris。火狐自动就支持了，不用做什么。

看起来这样就好了？我也以为如此，直到我离电脑远了一些……

问题

躺在床上玩手机时也可以用电脑听歌啦～你问我为什么不用手机听歌？因为我的电脑没有 NFC 功能，耳机切到手机碰一下就可以了，可是切到电脑上是要打命令抢连接的！所以就不切来切去啦，反正手机上的曲库和电脑上是同步的。

可是！耳机多媒体按键怎么不管用了呢？我瞟了一眼电脑，哦，它怎么屏幕还亮起来了？反复几次之后，我终于搞明白了——锁屏的时候按键事件全被锁屏软件给挡下来啦……

那怎么办呢？

我有看到 acpid 那边也收到了些事件，比如「cd/prev / CDPREV」和「cd/next / CDNEXT」。但是不是很稳定，时有时无，也没看到播放和暂停。再加上从作为系统服务的 acpid 将指令传到用户会话比较麻烦，就放弃了。

后来想到，既然能收到按键事件，那么应当有个输入设备在。xinput 看了一下，果然有个「WH-1000XM2 (AVRCP)」，用 evtest 在 /dev/input/ 也能找到对应的设备文件。那直接读这个设备文件不就好了？

解决

好是好，但是没权限啊。不过像/dev/video*之类的文件就有权限，是 systemd 拿 udev 规则给加上的。我之前也给 i2c 设备加过权限，只是那次是直接 chmod 了，这次想试试更优雅的方案——uaccess tag。

这个 uaccess tag 是 systemd 用来给当前会话的用户设备权限的，切换用户会话的时候权限会自动变化。不过没有文档 QAQ，所以只好自己研究了。最终的结果是这样：

SUBSYSTEM=="input", ATTRS{name}=="WH-1000XM2 (AVRCP)", TAG+="uaccess"

这个规则的序号需要小于70，不然赶不上处理 uaccess 的逻辑。sudo udevadm control --reload-rules 然后再 sudo udevadm trigger，就可以看到对应的 /dev/input/event* 文件上已经有 ACL 给我的用户权限了。不过多了写权限，问题不大。

然后就可以开始愉快地找设备文件、读取事件啦。我用 Rust 写的，日常练习嘛，顺便用用前不久看到的 eyre 和 tracing。有个 input-linux 库，不用自己拿 libc 调用 ioctl、定义 C 结构体了。不过这个库不支持从按键名到按键枚举值的转换，所以我 fork 了一下。蓝牙耳机说来来、说走走，所以 inotify 也是少不了的啦。然后还用 toml 整了个配置文件，好放出来给有需要的人用～

啊对了，程序里一上来就把对应的输入设备用 xinput 给禁用了。这样桌面环境就不会收到事件，不会唤醒屏幕，也不会有重复操作了。（不过它退出的时候并没有把设备重新启用，懒～）

代码

• bluekeyslistener

bwrap 是命令的名字。这个项目的名字叫 bubblewrap。它是一个使用 Linux 命名空间的非特权沙盒（有用户命名空间支持的话）。

我之前使用过 Gentoo 的 sandbox 工具。它是 Gentoo 用于打包的工具，使用的是 LD_PRELOAD 机制，所以并不可靠。主要用途也就是避免打包软件的时候不小心污染到用户家目录。

使用 bwrap 的话，限制是强制的，没那么容易绕过（至于像 Go 这种因为不使用 libc 而意外绕过就更难得了）。不过 bwrap 不会在触发限制的时候报错。

bwrap 的原理是，把 / 放到一个 tmpfs 上，然后需要允许访问的目录通过 bind mount 弄进来。所以没弄进来的部分就是不存在，写数据的话就存在内存里，用完就扔掉了。这一点和 systemd 也不一样——systemd 会把不允许的地方挂载一个没权限访问的目录过去。

bwrap 的挂载分为只读和可写挂载。默认是 nodev 的，所以在里边是不能挂载硬盘设备啥的。它也提供最简 /proc 和 /dev，需要手动指定。整个 / 都是通过命令行来一点点填充内容的，所以很容易漏掉部分内容（比如需要联网的时候忘记挂载 resolv.conf 或者 TLS 证书），而不会不小心允许不应当允许访问的地方（当然前提是不偷懒直接把外面的 / 挂载过去啦）。

至于别的命名空间，有 --unshare-all 选项，不用写一堆了。如果需要网络，就加个 --share-net（这个选项文档里没写）。没有别的网络方案，因为没特权，不能对网络接口进行各种操作。--die-with-parent 可以保证不会有残留进程一直跑着。

我目前的打包命令长这样：

alias makepkg='bwrap --unshare-all --share-net --die-with-parent \
  --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev \
  --symlink usr/bin /bin --symlink usr/bin /sbin --symlink usr/lib /lib --symlink usr/lib /lib64 \
  --bind $PWD /build/${PWD:t} --ro-bind /var/lib/pacman /var/lib/pacman --ro-bind ~/.ccache ~/.ccache \
  --bind ~/.cache/ccache ~/.cache/ccache --chdir /build/${PWD:t} /usr/bin/makepkg'

以后应该随着问题的出现还会修改的。

其实我学 bwrap 主要不是自己打包啦（毕竟基本上都交给 lilac 了），而是给 lilac 加固。Arch 的打包脚本是 shell 脚本，所以很多时候不执行脚本就没办法获取一些信息、进行某些操作。唉，这些发行版都喜欢糙快猛的风格，然后在上边打各种补丁。deb 和 rpm 的打包也都是基于 shell 脚本的。而 lilac 经常通过脚本编辑打包脚本，或者从 AUR 取，万一出点事情，把不该删的东西给删掉了，或者把私钥给上传了，就不好了。所以前些天我给 lilac 执行 PKGBUILD 的地方全部加上了 bwrap。期间还发现 makepkg --printsrcinfo 不就是读取 PKGBUILD 然后打印点信息嘛，竟然不断要求读取 install 脚本，还要对打包目录可写……

另一个用法是，跑不那么干净的软件。有些软件不得不用，又害怕它在自己家里拉屎，就可以让它在沙盒里放肆了。比如使用反斜杠作为文件路径分隔符写一堆奇怪文件名的 WPS Office。再比如不确定软件会不会到处拉屎，所以事先确认一下。我以前使用的是基于 systemd-nspawn 和 overlayfs 的方案（改进自基于 aufs 和 lxc 的方案所以名字没改），不过显然 bwrap 更轻量一些。跑 GUI 的话，我用的命令长这样：

bwrap --unshare-all --die-with-parent --ro-bind / / \
  --tmpfs /sys --tmpfs /home --tmpfs /tmp --tmpfs /run --proc /proc --dev /dev \
  --ro-bind ~/.fonts ~/.fonts --ro-bind ~/.config/fontconfig ~/.config/fontconfig \
  --bind ~/.cache/fontconfig ~/.cache/fontconfig --ro-bind ~/.Xauthority ~/.Xauthority \
  --ro-bind /tmp/.X11-unix /tmp/.X11-unix --ro-bind /run/user/$UID/bus /run/user/$UID/bus \
  --chdir ~ /bin/bash

其实还可以用来给别的发行版编译东西，取代我之前使用 systemd-nspawn 的方案。bwrap 在命令行上指定如何挂载，倒是十分方便灵活，很适合这种需要共享工作目录的情况呢。以后有需要的时候我再试试看。（好像一般人都是使用 docker / podman 的，但是我喜欢使用自己建立和维护的 rootfs，便于开发和调试，也更安全。）

和 bwrap 类似的工具还有 SELinux 和 AppArmor。它们是作用于整个系统的，Arch Linux 安装会很麻烦，对于我的需求也过于复杂。Firejail 是面向应用程序的，但是配置起来也挺不容易。bwrap 更偏重于提供底层功能而不是完整的解决方案，具体用法可以让用户自由发挥。

前些天尝试了一下 KDE 桌面环境，不过实在是没能用下去。

首先要说的是，KDE 桌面确实漂亮，非常养眼。设置项也挺多，可定制性还是挺不错的。只可惜问题同样很多。

首先是显示器缩放的问题。受限于 X11，KDE 只能设置一下全局的缩放比例。所以我们只好缩放显示器显示的画面。不幸的是，一向相当体贴的 KDE 此时却笨笨的，在使用 xrandr 设置好之后需要重启 plasmashell 来使其获取 xrandr 的设置更新：

kquitapp5 plasmashell && kstart5 plasmashell

KDE 的设置项很多，分门别类地在「设置」应用程序中集中列出来，然而问题也由此产生：同时只会显示一个「设置」窗口。也就是说，我配置快捷键时，想去窗口管理器那边看一看，调整一点选项，就必须放弃我当前打开的快捷键视图，放弃我键入的搜索词，并且选择「应用」或者「放弃」更改，才能切换到另一个「设置」组件中去。即使从 krunner 里打开某个组件的设置，它也会找到并更新已有的窗口。

我知道 Windows 10 也是这么个「单任务」设置的风格。可 Windows 10 也没有这么多可以设置的地方呀。后来获知有个命令可以打开单独组件的设置窗口。很不方便。它被隐藏起来的原因是这种窗口不能返回到组件列表界面，会让用户困惑。可是，为什么我不能同时打开「设置」的不同组件的多个窗口？单独组件的窗口会让用户困惑，那就不要用单独组件的窗口就好了嘛。

KDE 桌面还有个问题：启动特别慢。登录进入界面要好久，启动一个程序，它的图标也要跳好久窗口才会出现。不知道它在干什么。我甚至怀疑它是为了展示启动动画而故意推迟界面的显示。

KDE 有提供丰富的桌面部件。我往副显示器上放了一些系统状态的监视器——CPU、磁盘、网络啥的。然后问题来了：我凑齐了四个部件刚好形成2x2的网格，可是我要怎么对齐它们呢？并没有对齐的选项，也没有吸附的功能。在我找到它使用的配置文件并手动修改之前，我只能用肉眼瞅。可计算机不就是用来做这种人不擅长而机器擅长的事情的吗？

终端我还是用 GNOME Terminal，因为有些特性（比如超链接）只有它支持。但又出现问题了：它启动之后，pin 它的任务图标，或者通过任务栏图标创建新实例均会失败。把它 pin 到任务栏上，需要从主菜单的右键菜单里操作。即使这样，启动之后终端窗口还是会位于新的图标，旧图标还是不对应任何窗口。后来查了一下，GNOME 的东西都没有主动支持启动通知，导致 KDE 很多时候只能猜测，而这次它猜错了。解决的办法是给 GNOME Terminal 的 .desktop 文件加上正确的 StartupWMClass 项。这其实不是 KDE 的问题，但也没办法。KDE 不想为别人擦屁股，GNOME 不在意自己的软件在别的桌面上的可用性。

不过 Qt 写的 flameshot 我就不知道是怎么回事了。具体情况不记得了，反正就是显示异常。好像是全黑吧。我没来得及 debug 这个。

最后，让我决定放弃 KDE 的点来了：我设置不了我需要的窗口管理快捷键。

切换窗口，默认是 Alt-tab 的那个，我好不容易在「快捷键」设置里找到了添加更多快捷键的方式，但我发现除了 Alt-tab，我自定义的都不能连续切换窗口。按一下，切换一下，然后就切不动了，只能放开快捷键。后来了解到这是设置更新方面的问题，kwin_x11 --replace一下就有效了。

切窗口其实问题不大。问题大的是切显示器屏幕。两个功能：一、把焦点切到另一个屏幕；二、把当前窗口移到另一个屏幕上。

前者可以勾选「分隔屏幕焦点」选项，然后调整一下「阻止盗取焦点」的级别。我也不知道这个级别都是啥意思。「无」我能理解，「低」「中」「高」「终极」都是些啥？反正调整一下，确实可以把窗口焦点切换到另一个屏幕去了，除了鼠标不会跟着过去！另外测试过程中，有时候焦点会丢失——我不知道当前什么窗口获得了焦点，也不知道接下来谁会获得焦点。比 Mac OS X 里焦点跑到一个窗口也没有的 Finder 上还要神秘。

不过这个倒是可以自己写个脚本解决：使用 xrandr 获取屏幕的大小和位置，通过 X 的接口获取鼠标的位置并通过 Xtest 扩展来移动它，然后再用某个 X 的接口去设置窗口焦点——完全绕过 KDE 的功能。

然后我被另一个问题难住了——我怎么把窗口移到另一个屏幕上并且把焦点也移过去呢？使用文档匮乏的 kwin script 是可以把窗口移过去，然后我没能找到移动鼠标光标的 API。通过 X 是可以移窗口的同时移鼠标，但是我拿不到带窗口装饰的窗口位置信息。kwin 有一个 getWindowInfo 的 D-Bus 接口，但是它接收的那个 UUID 参数，我没找到获取的方法。

总结一下，KDE 对快捷键的支持并没有想像的那么好，尤其是多显示器的支持。快捷键的设置是通过图形界面来操作的，虽然直观但是对于大量快捷键的管理来说非常困难。而对于大显示器来说，通过快捷键来管理窗口是十分必要的——因为我更难肉眼找到我的鼠标光标去了哪里。

接下来，我打算一边忍受着 Awesome 3.5.9 的旧与 bug，一边尝试将 i3 改造成我需要的样子。

i3 有个东西叫「scratchpad」，和我在 Awesome 里用的 run_or_raise 功能有些类似。

我的需求是某些浮动窗口可以「招之即来，挥之即去」。上次尝试切换 i3 遇到的一大麻烦就是，我经常从终端里启动图形界面的程序，而启动完之后我得手动给我的终端找个地方放着。i3 不支持最小化，也只有十个带数字快捷键、可以快速访问的工作区，所以 scratchpad 很重要，但是它的行为我有些捉摸不定。

首先是 move scratchpad 这个命令。它会把当前 con（窗口或者容器）浮动、取消全屏，然后移到一个叫 __i3_scratch 的不显示的工作区。

然后是 scratchpad show 命令（动词放后边了）。如果没有指定条件，它有如下复杂的处理逻辑：

• 检查当前窗口是不是去过 scratchpad。如果是，就把它丢回去。
• 否则检查当前工作区是否有另外的 scratchpad 窗口。如果有，就给它焦点。
• 否则检查其它工作区是否有另外的 scratchpad 窗口。如果有，就把它移过来。
• 否则把 __i3_scratch 里最久没有「见到光」的窗口移过来。

如果指定了条件，那么这样检查匹配的窗口：

• 如果窗口不曾去过 scratchpad，什么也不做。
• 否则如果窗口去过 scratchpad 并且在当前工作区，就隐藏它。
• 否则就把它移过去。

总结一下，就是「回去，或者回来」。虽然动作的名字叫「show」，但其实是一个类似于 toggle 的功能。它的麻烦之处在于：如果你有多个去过 scratchpad 的窗口，你很难控制出现的是哪个窗口。一个绕过这个问题的办法是，总是带条件地使用 scratchpad。另一个小麻烦是：没有办法在匹配的窗口已经显示的时候，不要把它隐藏掉——有时候我只是习惯性地呼叫我的终端，而不看它是不是已经在我面前了。

对于浮动窗口，i3 有很多奇怪的限制，或者说是未实现：

• 不支持最小化
• 浮动窗口也不能显示在平铺窗口之下（加上上一条，就是没办法暂时藏起来）
• 不支持最大化（手动调整窗口大小无法自动适配显示器大小，也没有「恢复」一说）
• 不支持显示在最上层（当你在 GIMP 里开了一堆图片需要局部对比时）
• 有全屏窗口时不能显示浮动窗口（看视频无法临时使用浮动窗口查个单词啥的）
• 切换窗口时，平铺窗口和浮动窗口是隔绝的（需要单独的快捷键来切换）