依云's Blog

前天得知 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 里开了一堆图片需要局部对比时）
• 有全屏窗口时不能显示浮动窗口（看视频无法临时使用浮动窗口查个单词啥的）
• 切换窗口时，平铺窗口和浮动窗口是隔绝的（需要单独的快捷键来切换）

首先，我是用 X11 窗口系统的，不同屏幕分别设置肯定没戏。所以只好让笔记本电脑的屏幕迁就一下我的4K主屏啦，把笔记本屏幕缩放一下。算一下 scale 值：192 / 120 = 1.6。不是整数，会糊，可总比放大两倍的巨大界面要好。

xrandr --output eDP-1 --scale 1.6 --auto --output DP-2 --auto --pos 3072x0 --primary --fb 6912x2160

这里要注意的是，要指定--pos（或者--panning），不然会重叠；要指定--fb，不然鼠标可能会有部分区域去不了。

然后开始设置。本来我是尝试了一下 KDE 的，但因为我将在下一篇文章中写的原因而放弃，回到了 Awesome。不过也不是全无收获。我把 KDE 的配置方案拿过来用了。你想问怎么拿的？我 btrfs 的文件系统，做好快照再 rsync -n 对比一下它动了哪些文件就有了。

首先是 X11 的资源。在~/.Xresources里写上Xft.dpi: 192，然后xrdb -merge ~/.Xresources一下就好了。顺便再xrandr --dpi 192一下，听说有些程序会读这个。

然后是 GTK。GTK 2 就放弃吧，没办法。文字会按设置的 Xft.dpi 放大，图标啥的不会。GTk 3，要设置两个环境变量：

export GDK_SCALE=2 GDK_DPI_SCALE=0.5

前一个是把界面放大，后一个是把文字缩回去，因为文字已经按 Xft.dpi 放大过，不能再放大一次了。

再然后是 Qt。Qt4 早卸载干净了不用管。Qt5 嘛，也不用管。它自己会处理好。有个按不同屏幕缩放的环境变量QT_SCREEN_SCALE_FACTORS，效果跟 Windows 10 差不多的。但是我为了照顾其它程序已经把屏幕给 scale 过了，就不需要设置这个了。你要设置个QT_AUTO_SCREEN_SCALE_FACTOR=0也行，但这个是默认行为。

最后是个别的程序。

Telegram 直接在设置里关掉「默认界面缩放比例」并且设置缩放比例为 300% 就好了。我也不知道为什么，Telegram 默认的字总是很小。之前 120dpi 的时候我要 200% 缩放，现在 192dpi 需要 300% 缩放了。

YouTube，就是那个网站啦。它其实没什么显示上的问题，只是死活不会给我自动选择 1080p 以上的分辨率。经过仔细二分测试之后发现，把火狐的配置文件夹下的storage/default/https+++www.youtube.com目录删掉之后就好了。没发现删掉这个会有其它影响。

mpv 要修改配置文件，加上no-hidpi-window-scale参数，不然会把视频自动放大，4K视频一打开会只能看到四分之一的画面。加上这个参数，默认窗口大小时，一个视频里的像素会对应一个显示器上的像素，不大不小刚刚好。mpv 文档上说这是 OS X 系统上的默认行为，可我这是 Linux 桌面啊，你把别的平台上的习惯搬过来是几个意思？另外我加了个demuxer-readahead-secs = 20选项。我的大文件都在机械硬盘上，4K 码率又比较高，不多预读一点容易卡。

我的 qemu 之前使用的是-display gtk，也坏掉了。窗口那么大，虚拟机只用左下角那里四分之一的空间。spicy 也有问题，会告诉虚拟机只有 1080p。解决方法是 unset GDK_SCALE GDK_DPI_SCALE。它们在放大了自己的界面的同时，把显示的虚拟机的内容也给放大了，所以干脆叫它们别动。也没什么别的影响。

哦还有 Zoom。设置个QT_AUTO_SCREEN_SCALE_FACTOR=1似乎就好了？我试了一下QT_SCREEN_SCALE_FACTORS，会导致很怪异的行为。

以上解决了显示大小的问题，但我发现还有个问题：我的鼠标光标时大时小的……从 KDE 那边弄来几个设置之后就好了，而且主题也更加一致了呢。

首先是设置 xcursor 环境变量：

export XCURSOR_THEME=Vanilla-DMZ XCURSOR_SIZE=36

听说对应的 X 资源大家都不理睬，那我也就不设好了。

然后是 GTK 2 的~/.gtkrc-2.0文件里写上：

gtk-cursor-theme-name = "Vanilla-DMZ"
gtk-cursor-theme-size = 36

再接下来是 GTK 3 的~/.config/gtk-3.0/settings.ini：

[Settings]
gtk-cursor-theme-name = Vanilla-DMZ
gtk-cursor-theme-size = 36

然后又没了。天知道为什么 Qt 那边啥都不干就好好的，GTK 却这么麻烦。

啊，你问这些环境变量在哪里设？我给写~/.xprofile里了。不过这还不够。有些 GUI 程序会由用户的 systemd启动（比如我的 Telegram 是由 systemd 启动的，为了在内存用得太多的时候自动重启），有些 GUI 程序会由 D-Bus 激活（比如 gnome-terminal）。这些是和登录会话分开的，所以要手动导入一下。以下是我的 .xprofile 中导入图形界面相关环境变量的部分：

_envs=(
  GDK_SCALE GDK_DPI_SCALE
  XCURSOR_THEME XCURSOR_SIZE
  XMODIFIERS QT_IM_MODULE GTK_IM_MODULE
  LIBVA_DRIVER_NAME GST_VAAPI_ALL_DRIVERS
)
dbus-update-activation-environment "${_envs[@]}"
systemctl --user import-environment "${_envs[@]}"

至于登录界面怎么办，我是在 lightdm 的 display-setup-script 里，跑了跑 xrandr，设置了一下 Xft.dpi 资源。环境变量啥的没动，反正用不上。当然你也可以去改~lightdm/.pam_environment来设环境变量，反正现在 Arch Linux 还是读它的。别的 dm 同理。

缘起

我就是买了个4K显示器，咋这么多事呢……（有两篇文章还在路上）

第一个问题是，我的显卡 vGPU 最高只支持 1920x1200 的分辨率。行吧，我缩放成了吧？嘿嘿，-display gtk 的缩放不会保持比例，我只好算了算最大保持比例的大小，然后窗口切成浮动，再调用命令调整到指定的大小：

sleep 1 && xdotool getactivewindow windowsize 3280 2122

然后还要居中放置一下。多麻烦！

第二个问题是，我想在虚拟机里试试 i3，但是我的按键总是会被外边捕获。Super 键基本上是 Awesome 在用，而 Alt 键会撞上这个 GTK 窗口菜单栏的快捷键。

配置

经过多番尝试和摸索之后，确定了如下的参数：

  -display egl-headless,gl=on,rendernode=/dev/dri/renderD128
  -spice unix,addr=/run/user/1000/qemu/ArchKDE/spice.sock,disable-ticketing
  -device virtio-serial-pci
  -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0
  -chardev spicevmc,id=spicechannel0,name=vdagent

当然要gl=on啦，不然我怎么玩特效，我还不如回到 vbox 去呢（啊不，我的 vbox 不喜欢 btrfs，经常出错然后只读挂载，所以已经被删掉了）。要指定rendernode，不然它会 fallback 到 llvmpipe，然后还段错误崩掉……这也是我不-display spice-app的原因。

后边三行是从这个 QEMU + Spice with Copy & Paste 抄来的。搜索问题时不小心遇见，然后解决了这个我一直没有处理的问题。SPICE 不但能共享剪贴板，而且还支持 PRIMARY 选择区呢～虚拟机里要安装 spice-vdagent 并启动相应的服务。

然后是客户端的选择。一个很神奇的地方是，virt-viewer 看上去轻量，实际上只是选项少而已。它不光拖进来个 gtk-vnc 依赖，还把 libvirt 都给我带上了……然后 GNOME 的 vinagre，我不知道为啥，它就是连不上我的 spice+unix 地址。哦对了，virt-viewer 直接敲命令调用也是连不上，只能用 xdg-open 才能正常打开。

virt-viewer 有个依赖叫 spice-gtk。我试着 pacman -Ql 了一下，还真找到个 spicy 工具。比 virt-viewer 轻量多了，选项也更为丰富，比如可以选择不 grab 键盘。

一点额外的东西

在群里听说了 virtio-fs 共享方案，听说比 virtio + 9p 更高效。然后我用它成功取代了之前用的 NFS 方案（反正我的 vbox 虚拟机已经被删掉啦）。NFS 的服务也可以卸载啦（开放一堆端口到公网，看着有点怕怕的，虽然是 IPv6 地址不太会被扫到，但知道我的地址的咋办呢）。

virtio-fs 相比 virtio + 9p 的另一个优点是，和 NFS 一样，virtiofsd 是以 root 权限运行的，所以可以写入我的 pacman 缓存。qemu 那个 9p 似乎没有办法。至于启动嘛，用 systemd abstract socket 触发一下就好了。

另外，我使用 GVT-g 和 virtio 输出视频信号时，均遇到了声音在视频画面变化时声音卡顿的情况。一个绕过的办法是，通过设置 PULSE_SERVER 环境变量以及加载 module-native-protocol-tcp 模块，将音频信号直接通过网络发送到宿主机上，一点也不卡！

2024年03月20日更新：pacman 6.1.0 增加了 CacheServer 的支持，已经不需要使用本文这种办法啦～

Arch Linux 就是要追新！要追新自然要选择一个更新及时的软件仓库镜像啦，比如国内的 TUNA、USTC 同步都很及时。但是呢，这俩难兄难弟最近一段时间有些吃不消了，导致下载包的时候很慢，甚至超时失败，使用体验真糟糕。如果直接用上游镜像，比如 pkgbuild.com，漂洋过海的，也挺慢的。

而国内另一些镜像，比如网易、腾讯云、阿里云、华为云，他们要么有 CDN，要么线路很好，下载速度飞快。但是呢，他们基本上每天才同步一次，阿里云还时不时连续数天都没能同步成功，这让喜欢追新的 Arch Linux 用户多不舒服呀。当群里的小伙伴们都用上了最新版本的软件，体会到了让人心痒痒的新特性和 bug 时，你 -Syu 却是「今日无事可做」，真是扫兴呢。

和最新的镜像同步，从最快的镜像下载，真的不可兼得吗？

非也。只需要稍微配置一下，用上我的 pacsync 脚本，就可以啦～

配置方式是，为 /etc/pacman.d 下的镜像列表文件创建一个.sync后缀的同名文件，里边指定用于同步的镜像，而不带.sync后缀的文件里按优先级列出多个镜像。pacman 在下载文件时，会按顺序依次尝试列出的镜像，如果遇到更新不及时 404 的时候，就会尝试另一个。这样，可以仅在下载快的镜像里还没有需要的包文件时，才转而从比较慢的镜像下载。

而需要同步 pacman 数据库的时候，使用pacsync脚本取代pacman -Sy。脚本会使用 bind mount 用.sync文件取代不.sync的版本，就能同步到最新的数据库了。原来的pacman -Syu命令要拆开来用，先pacsync再pacman -Su了。

脚本里使用了单独的挂载空间并且将挂载改为了私有，所以并不会影响到外边。

一次系统升级之后，我的许多 Python 程序突然开始报错：

[...]
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2762, in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1415, in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1405, in get_metadata
    value = self._get(path)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1609, in _get
    with open(path, 'rb') as stream:
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO'

WTF 滚坏了！立即回滚！

回滚完之后，我开始调查这个事件——因为 [archlinuxcn] 的这个包是我管的呀。而且我记得之前也遇到过一次类似的情况，当时没有深究。

检查一下软件包里的文件的权限：

>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep PKG-INFO
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep -- ----
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
-rw------- root/root     12078 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/SOURCES.txt
-rw------- root/root         1 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/dependency_links.txt
-rw------- root/root        27 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/requires.txt
-rw------- root/root        15 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/top_level.txt

好奇怪，Telethon 这些包信息文件怎么只让 root 读了呢？

从 PyPI 上下载 Telethon 的原始 tar 归档回来看看，发现最近几个版本里，文件权限全部只有自己可以读（-rw-------），而所有者是 u0_a167/10167。开发者突然在 Android 系统上打包了呢……安装的时候，部分文件的权限被保留了下来（Arch Linux 打包时强烈反对使用 root 权限执行，因此我用 devtools 打包，解包部分自然是普通用户操作的，所有者无法被保留）。

然后我又看了一下之前的版本，哦豁，所有者成开发者的 id 了，但是有三个版本的 pyc 文件，还有好几个 pyc 文件都是 -rwxrwxrwx。大概系统上的低权限用户可以去改改，然后看谁跑 Telegram 机器人就拿谁的权限？

经过跟开发者的讨论，最终干掉了 pyc 文件，也不在 Android 上打包了。777 权限问题还待解决。不过我更在意的是，为什么会发生这种状况呢？setuptools 干嘛不修一修呢？别的工具创建的用于发布的 tar 归档会不会有类似的问题呢？

结果找了找，发现 setuptools 前年就有人报告这个问题，但是并没有解决。行吧，我打包时统一修正一下权限好了……

下一个 GitHub 生成的 tar 归档看看？咦，-rw-rw-r-- root/root，是处理过了么？啊对，git archive 生成的包是怎么样的？去试了试，原来一样的啊。看来 git 想到了这个问题并且处理了，只是 002 的 umask 有点意外。

Arch Linux 为了普通用户打出文件为 root 所有的 tar 归档使用了 fakeroot，那么 git 是怎么实现的呢？翻了翻代码，git 是自己生成 tar 文件的，写死了所有者是 root/root，但是权限位还是有专门的 umask，默认是 002。可以配置，比如git config --global tar.umask user一下，就会取当前 umask 作为 tar 归档里文件的 umask 了。

至于传统的 GNU autotools 构建系统创建的 tar 归档，我也创建了一个看了一下，并没有特殊处理，跟手动跑 tar 一样。

序

最近，Arch Linux 的 pam 包将更新到 1.4.0，然后因为一个字符的变化，不少中文用户都开始避难了：pam_env 将默认不读取用户的环境变量设置。许多中文用户使用~/.pam_environment文件来配置 fcitx 输入法所需要的那三个环境变量。更新之后，这些配置将不再生效，意味着他们可能无法输入中文了，于是大家热烈讨论现在要在哪里配置环境变量比较好。

当然了，在 pam 的配置文件里加上user_readenv=1就可以恢复原先的行为。只是，pam 的开发者这么改当然是有原因的：CVE-2010-4708。简单地说，就是在鉴权模块里设置用户指定的环境变量不安全，怕被提权。

2020年08月20日更新：Arch Linux 打包时添加了以上这个配置。

当然啦，桌面用户完全可以去改系统级的环境变量设置，只要你愿意让你个人的配置信息跑到系统配置那边去的话。

正文

用户经常需要设置一些环境变量，比如输入法，比如语言和地区选项，比如自定义的 PATH，等等。然而 Linux 的环境变量又不像 Windows 那样有一个专门设置所谓「系统环境变量」的地方，而是所有环境变量全部由子进程继承父进程获得，这么一路继承下来的。于是，想要给所有想设置上的进程都设置上，就不是一件简单的事情了。

这里关注的是桌面用户，自然首先从图形界面说起。

使用 X11 的桌面环境，通常通过 display manager 来登录，比如 lightdm 和 sddm。这俩都支持 ~/.xprofile。这个文件会在启动过程中被 source，使用的 shell 是由 dm 自己确定的。lightdm 和 sddm 都是用的 /bin/sh（分别位于 /etc/lightdm/Xsession 和 /usr/share/sddm/scripts/Xsession 文件里）。可以看到，除了读取 .xprofile 外，lightdm 也会读取 .profile。sddm 甚至连 bash、zsh、tcsh、fish 的启动配置脚本都给读了。

对于 Wayland，我这儿只有 sddm，类似的，也是各种 shell 的都给你读了。（当然就不读 X11 相关的东西了。）

而对于手动 startx 的用户，~/.xinitrc 里自己写上呗。还有 VNC 啥的，也都可以自己看启动脚本找到方法。

没有图形界面的登录，通常是从 tty 或者 ssh 登录。这两者都是登录到命令行 shell。写在 shell 配置里就可以了。具体到 zsh，我是写到 ~/.zprofile，这样不管是否交互，只要是登录 shell 就执行，不登录的大概已经继承到了。另外有些情况可能写这儿也没有用，比如 cron 调用的时候。非要搞的话其实可以写到 ~/.zshenv，这个基本上所有的 zsh 都会读，只能被系统级设置或者命令行参数禁用掉。而如果是 bash 用户，.bash_profile .bash_login .profile 这仨，会读找到的第一个（sddm 也会按这个顺序找，但是 lightdm 只会找 .profile）。Arch Linux 现在默认会给新用户建立 .bash_profile，我建议 bash 用户把它改名成 .profile。这里有个图 ，大致上说明了 bash 和 zsh 不同情况下会读取的配置文件。

systemd 用户实例也有一份环境变量，用于通过 systemd 启动的用户级服务，通过 systemctl --user 的子命令可以查看和更新。D-Bus 也有一份，可以通过 dbus-update-activation-environment 命令来更新。这俩通常不需要用户操心，桌面环境应该会维护好。

如果你用 tmux 的话，那么 tmux 还有一份，用于新创建的窗格。tmux 会在被连接时更新 update-environment 选项指定的环境变量。当然你也可以用 tmux setenv 子命令去更新。这个尤其值得注意，因为 tmux 可能在不同的环境中被连接，导致环境变量混乱（比如 X11 下没有 DISPLAY 变量）。

要注意的一点是，不同的登录过程并不是只会读取自己专属的配置文件，尽管大家都在努力，也并没有完全统一好用的配置文件。所以有些环境变量，你可能想尽量避免重复设置（比如冗长重复的 PATH 项就很讨厌）。好在这些都是 shell 脚本，不光能设置环境变量，也能做条件判断。

要查看当前进程的环境变量，可以用 env 命令。要查看别的进程的，去读它的 /proc/PID/environ 文件，或者开个 htop 然后在进程上按 e 键。要看看某个环境变量在不同进程里是什么情况，可以用我写的小工具 compare-env。

跋

Linux 软件生态的特点就是这样，没有谁规定一定要用怎样的方式做一件事情，所以大家的想法总会有些出入，就导致设置个环境变量还有这么一大群配置文件（systemd 还有一份呢，我还没读没试所以没说）。但另一方面，理解它们也是十分容易的：不用猜测，不用撞大运般地耗费时间去尝试，顺着代码摸过去，总能弄明白软件的行事逻辑。即使文档像 pam_env 那样前后矛盾，也有源代码这条路可以精确刻画软件的行为。