依云's Blog

我在上一篇说到，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 的特效太绚烂太怀旧让我偏心了～

我在上一篇说到，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 真的挺顺滑的。

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

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

前天得知 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 真的挺顺滑的。

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

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

前些天尝试了一下 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 改造成我需要的样子。

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

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

在之前的文章中介绍过，X Window 中有个很方便的名叫 PRIMARY 的「剪贴板」，选中即复制，中键即粘贴。

然而问题来了：我在输入的过程中需要之前选中的内容怎么办？又或者我的内容是通过 xsel、Vim 等程序以键盘的方式选中的，我还要继续打字，要怎么粘贴才比较流畅呢？

我之前的解决方案是 fcitx 自带的 fcitx-clipboard 扩展。启用之后可以按 Ctrl-; 来显示几条最近复制的内容。如果启用了的话，第一条、第三至最后，都来自常见的 CLIPBOARD 选区，而第二条（如果用了够久，第一条及本条有的话）是 PRIMARY 选区的内容。于是我只需要按 Ctrl-; 2 就可以粘贴了。

这么用了很久之后，我读到了一篇讲 X Window 选区是如何工作的文章。然后突然意识到一个问题：fcitx-clipboard 是什么时候请求选区内容的呢？

这里先科普一下好了。X Window 的每一个选区，是由某个窗口作为所有者持有的，并且在被请求时输出内容。「复制」的时候，内容并不会被存起来放在某处，而是窗口跟 X 服务器说，「我现在是这个选区的所有者了！」至于是哪个，取决于应用程序（及用户的操作）。通常用户明确的「复制」操作（Ctrl-C 快捷键、菜单项等）会使用 CLIPBOARD 选区，而只是选中内容的话，会使用 PRIMARY 选区。我还没有见到有程序使用别的选区的。

如果使用的是 PRIMARY 选区，这个时候，旧的所有者（如果存在的话）会失去选区。在 Vim / GVim 里，可视区域会由「Visual」高亮组变为「VIsualNOS」高亮组（在我的主题里就是变灰了），而多数终端，选中的区域会失去高亮。下一次，有程序想要「粘贴」PRIMARY 选区，就会跟 X 服务器讲，请把 PRIMARY 选区的内容，以某个指定的格式写到指定窗口的指定属性上。然后 X 服务器把请求传给选区所有者，选区所有者就去按要求写属性。当然选区所有者也可能会拒绝请求，比如它拥有的是文本而请求方想要图片。当然后来大家要粘贴的内容比较大了，于是就有了 INCR 机制来一点一点地传数据。

这样的流程，也可以解释，为什么我往 Telegram 里粘贴图片，GIMP 却莫名其妙地挂掉了……

所以啦，在一个程序里复制之后，退出那个程序，你就粘贴不出来东西啦。可这样岂不是很不方便？是啊，所以又有了剪贴板管理器。它们的工作原理我还没有研究，猜想是支持 SAVE_TARGETS 的话，就等着对方退出之前把内容传过来，不支持的话一复制就传过来。

fcitx-clipboard 是这么干的：选区一有变化，它就获取其纯文本格式的内容，符合一定条件的就存起来。所以，当我在 Vim 里用键盘不断进入可视模式选东西进行各种操作时，因为我设置了 clipboard=autoselect 选项，Vim 会不断地通告「我拥有 PRIMARY 选区啦！」「我这边的 PRIMARY 选区又更新啦！」结果就是，fcitx-clipboard 会不断地把我在 Vim 中选中的内容给拿过去。

就那么点数据，本地传来传去当然没啥问题。但是，当我通过 ssh 使用的时候，我发现我在 Vim 里每一次扩大可视区域都如此地艰难。不得已只好关了 autoselect 选项。当时我还以为就选点文本，怎么就这么慢呢，谁曾想到，每一次更新可视区域，fcitx-clipboard 都会把我选中的文本请求一份……

那么好吧，不用 fcitx-clipboard 了。于是问题又回到了原点：怎么通过键盘粘贴 PRIMARY 选区呢？用程序把鼠标移过去点中键是不行的，因为程序不会知道当前光标在哪里。通过 xdotool type 也行，但是这样一个个字地输入，而且还不仅仅是 ASCII，鬼晓得有多少程序跟 Minecraft 一样会处理不过来而丢字？而且，怎么判断当前是否是输入文本的状态也是个问题。所以我还是走输入法这条路了。

其实这事完成并不难，从肥猫的傲娇扩展开始改，照猫画虎地注册热键，然后请求选区，提交文本。可我遇到一个很奇怪的 bug：扩展加载了，但是热键不生效。为了调试这问题，我通过手机 termux ssh 连过来，tmux attach 上，然后用蓝牙键盘对着屏幕里那只由于 fcitx 被 gdb 停下来了因此从电脑收不到键盘事件的 tmux 调试好久，最终发现热键怎么没注册上，才找到配置文件里一处没有被更新到的 tsundere 字样……

这个扩展名叫 fcitx-paste-primary，源码放 GitHub 上了。Arch Linux 用户可以通过 AUR 或者 archlinuxcn 仓库安装 fcitx-paste-primary-git。

对了，差点忘了说，这个扩展「粘贴」的时候，只是把会被粘贴的文本提交给应用程序，程序并不会认为是真的粘贴，所以在一些需要区分的程序里会出现问题。比如 Vim 和 zsh，都会把来自 fcitx-paste-primary 的文本当作用户输入而非粘贴而可能造成问题。

在之前的文章中介绍过，X Window 中有个很方便的名叫 PRIMARY 的「剪贴板」，选中即复制，中键即粘贴。

然而问题来了：我在输入的过程中需要之前选中的内容怎么办？又或者我的内容是通过 xsel、Vim 等程序以键盘的方式选中的，我还要继续打字，要怎么粘贴才比较流畅呢？

我之前的解决方案是 fcitx 自带的 fcitx-clipboard 扩展。启用之后可以按 Ctrl-; 来显示几条最近复制的内容。如果启用了的话，第一条、第三至最后，都来自常见的 CLIPBOARD 选区，而第二条（如果用了够久，第一条及本条有的话）是 PRIMARY 选区的内容。于是我只需要按 Ctrl-; 2 就可以粘贴了。

这么用了很久之后，我读到了一篇讲 X Window 选区是如何工作的文章。然后突然意识到一个问题：fcitx-clipboard 是什么时候请求选区内容的呢？

这里先科普一下好了。X Window 的每一个选区，是由某个窗口作为所有者持有的，并且在被请求时输出内容。「复制」的时候，内容并不会被存起来放在某处，而是窗口跟 X 服务器说，「我现在是这个选区的所有者了！」至于是哪个，取决于应用程序（及用户的操作）。通常用户明确的「复制」操作（Ctrl-C 快捷键、菜单项等）会使用 CLIPBOARD 选区，而只是选中内容的话，会使用 PRIMARY 选区。我还没有见到有程序使用别的选区的。

如果使用的是 PRIMARY 选区，这个时候，旧的所有者（如果存在的话）会失去选区。在 Vim / GVim 里，可视区域会由「Visual」高亮组变为「VIsualNOS」高亮组（在我的主题里就是变灰了），而多数终端，选中的区域会失去高亮。下一次，有程序想要「粘贴」PRIMARY 选区，就会跟 X 服务器讲，请把 PRIMARY 选区的内容，以某个指定的格式写到指定窗口的指定属性上。然后 X 服务器把请求传给选区所有者，选区所有者就去按要求写属性。当然选区所有者也可能会拒绝请求，比如它拥有的是文本而请求方想要图片。当然后来大家要粘贴的内容比较大了，于是就有了 INCR 机制来一点一点地传数据。

这样的流程，也可以解释，为什么我往 Telegram 里粘贴图片，GIMP 却莫名其妙地挂掉了……

所以啦，在一个程序里复制之后，退出那个程序，你就粘贴不出来东西啦。可这样岂不是很不方便？是啊，所以又有了剪贴板管理器。它们的工作原理我还没有研究，猜想是支持 SAVE_TARGETS 的话，就等着对方退出之前把内容传过来，不支持的话一复制就传过来。

fcitx-clipboard 是这么干的：选区一有变化，它就获取其纯文本格式的内容，符合一定条件的就存起来。所以，当我在 Vim 里用键盘不断进入可视模式选东西进行各种操作时，因为我设置了 clipboard=autoselect 选项，Vim 会不断地通告「我拥有 PRIMARY 选区啦！」「我这边的 PRIMARY 选区又更新啦！」结果就是，fcitx-clipboard 会不断地把我在 Vim 中选中的内容给拿过去。

就那么点数据，本地传来传去当然没啥问题。但是，当我通过 ssh 使用的时候，我发现我在 Vim 里每一次扩大可视区域都如此地艰难。不得已只好关了 autoselect 选项。当时我还以为就选点文本，怎么就这么慢呢，谁曾想到，每一次更新可视区域，fcitx-clipboard 都会把我选中的文本请求一份……

那么好吧，不用 fcitx-clipboard 了。于是问题又回到了原点：怎么通过键盘粘贴 PRIMARY 选区呢？用程序把鼠标移过去点中键是不行的，因为程序不会知道当前光标在哪里。通过 xdotool type 也行，但是这样一个个字地输入，而且还不仅仅是 ASCII，鬼晓得有多少程序跟 Minecraft 一样会处理不过来而丢字？而且，怎么判断当前是否是输入文本的状态也是个问题。所以我还是走输入法这条路了。

其实这事完成并不难，从肥猫的傲娇扩展开始改，照猫画虎地注册热键，然后请求选区，提交文本。可我遇到一个很奇怪的 bug：扩展加载了，但是热键不生效。为了调试这问题，我通过手机 termux ssh 连过来，tmux attach 上，然后用蓝牙键盘对着屏幕里那只由于 fcitx 被 gdb 停下来了因此从电脑收不到键盘事件的 tmux 调试好久，最终发现热键怎么没注册上，才找到配置文件里一处没有被更新到的 tsundere 字样……

这个扩展名叫 fcitx-paste-primary，源码放 GitHub 上了。Arch Linux 用户可以通过 AUR 或者 archlinuxcn 仓库安装 fcitx-paste-primary-git。

对了，差点忘了说，这个扩展「粘贴」的时候，只是把会被粘贴的文本提交给应用程序，程序并不会认为是真的粘贴，所以在一些需要区分的程序里会出现问题。比如 Vim 和 zsh，都会把来自 fcitx-paste-primary 的文本当作用户输入而非粘贴而可能造成问题。