Linux 使用优化记录（一）：终端与 Wayland 使用优化

合集说明

记录日常 Linux 使用中遇到的小问题与调优过程：现象 → 排查 → 解决 → 总结，方便日后检索复用。本文是第一篇。

现象

从文件管理器（Nautilus）把文件拖进终端窗口，期望在命令行插入文件路径：

• kitty：拖放正常，路径直接插入
• Alacritty：完全无反应，鼠标光标没有任何反馈

排查过程

1. 升级版本无效

当时 Alacritty 是 apt 装的 0.13.2，先用 cargo 升级到最新的 0.17.0：

cargo install alacritty --version 0.17.0 --locked

~/.cargo/bin 在 PATH 最前，新版本生效（alacritty --version 确认）。但拖放依旧不行。

2. 确认是上游未实现，而非配置问题

查 GitHub 找到对应 issue：alacritty/alacritty#4010 "Drag and drop to paste file path doesn't work under Wayland"，状态 Open，被上游 winit#1881 阻塞。

关键时间线：

• winit 的 Wayland DnD 实现（PR #4571）2026-07-16 才合并到 master，尚未发布到 crates.io
• Alacritty 还在用 crates.io 的 winit 0.30.x，自然没有该功能
• 也就是说：Alacritty 在 Wayland 下不支持拖放是功能缺失，升级解决不了，只能等 winit 发版 + Alacritty 适配

3. 尝试 X11 后端：WINIT_UNIX_BACKEND 踩坑

issue 里确认 X11 模式下拖放可用，于是尝试强制 X11 后端：

WINIT_UNIX_BACKEND=x11 alacritty

无效！ 用 lsof 检查进程，发现它监听的还是 Alacritty-wayland-0-*.sock，实际跑的还是 Wayland 后端。

查 winit 源码（platform_impl/linux/mod.rs 的 EventLoop::new）才明白：winit 0.29 起已移除 WINIT_UNIX_BACKEND 环境变量，后端选择只看 WAYLAND_DISPLAY / DISPLAY：

Breaking: WINIT_UNIX_BACKEND was removed in favor of standard WAYLAND_DISPLAY and DISPLAY variables.（winit 0.29 changelog）

也就是说旧教程里的 WINIT_UNIX_BACKEND=x11 对现代 winit 是无效的，坑了不少人。

解决方案

正确的强制 X11 后端方式是 unset WAYLAND_DISPLAY，winit 检测不到 Wayland 后自然 fallback 到 X11：

env -u WAYLAND_DISPLAY alacritty

验证方法（确认窗口真的跑在 X11）：

# 窗口应出现在 X11 窗口树，带 mutter-x11-frames 装饰
DISPLAY=:0 wmctrl -l

# 进程不再监听 wayland socket，且无 Alacritty-wayland-*.sock
lsof -p $(pgrep -x alacritty) | grep -E 'Alacritty.*sock'

实测从 Nautilus 拖文件，路径正常插入。

固化启动：覆盖 desktop 文件

改系统 desktop 文件不持久（升级 apt 包会覆盖），在用户级同名文件覆盖即可：

# ~/.local/share/applications/Alacritty.desktop
[Desktop Entry]
Type=Application
TryExec=alacritty
Exec=env -u WAYLAND_DISPLAY alacritty
Icon=Alacritty
Terminal=false
Categories=System;TerminalEmulator;

Name=Alacritty
GenericName=Terminal
Comment=A fast, cross-platform, OpenGL terminal emulator
StartupNotify=true
StartupWMClass=Alacritty
Actions=New;

[Desktop Action New]
Name=New Terminal
Exec=env -u WAYLAND_DISPLAY alacritty

desktop-file-validate ~/.local/share/applications/Alacritty.desktop

之后从应用菜单/桌面启动的 Alacritty 都走 X11 后端。

问题二：X11 后端下字体变大

现象

改完 desktop 文件后，从应用菜单启动的 Alacritty 字体明显变大（18pt 看起来像 27pt），而之前 Wayland 后端时正常。

原因分析

排查链路：

1. GNOME 全局设了 text-scaling-factor = 1.5（GNOME Tweaks → 字体 → 缩放因子，或 gsettings 设置，默认 1.0）
2. GNOME 会话会把该值同步给 XWayland：Xft.dpi = 96 × 1.5 = 144（可用 xrdb -q | grep Xft.dpi 确认）
3. winit 的 X11 后端按 Xft.dpi / 96 计算窗口 scale factor → 1.5
4. Alacritty 字体大小 = font.size (18pt) × scale factor → 视觉 27pt

Wayland 后端不读 Xft.dpi（用 compositor 的 surface scale），所以之前从终端启动（Wayland）完全正常，切到 X11 后端才暴露。

解决方案

两个层次，可叠加：

1. 单独压掉 Alacritty 的缩放（推荐，不影响全局）：winit 支持 WINIT_X11_SCALE_FACTOR 环境变量强制 scale factor（数字，或 randr 用 xrandr 自算）：

Exec=env -u WAYLAND_DISPLAY WINIT_X11_SCALE_FACTOR=1.0 alacritty

本次最终取舍：全局恢复 1.5（桌面文字大更好读），Alacritty 保持 WINIT_X11_SCALE_FACTOR=1.0 单独压掉——两套方案叠加，互不冲突。改全局到 1.0 实测发现桌面文字偏小，又改回了 1.5。

2. 关掉全局文本缩放（影响所有 GTK 应用，如标题栏、菜单）：

gsettings set org.gnome.desktop.interface text-scaling-factor 1.0

如果调 1.5 只是为了可读性，可以改用系统字体大小替代（如 font-name 'Ubuntu Sans 12'），两者效果不同但都能放大界面。

小结

问题三：kitty ssh 后每次按键出现大量重复字符

现象

kitty 终端本地开 zsh 一切正常；ssh dev 到远程服务器后，每次键盘输入都出现很多字符（重复/乱画），几乎没法用。

排查过程

1. 先排除远端 shell 配置：用 rmux（tmux 类复用器）连 dev，TERM=tmux-256color 时输入完全正常 → 远端 zsh/oh-my-zsh 配置本身没问题
2. 模拟 kitty 场景：TERM=xterm-kitty ssh dev 复现问题——发送 1 个字符显示 2 个，命令被双重渲染（如 zsh -fzsh -f）
3. 找到报错：远端运行 zsh -f 报 zsh: can't find terminal definition for xterm-kitty；dpkg -S xterm-kitty 显示无任何包拥有该 terminfo
4. 根因：kitty 连接时把本地 TERM=xterm-kitty 传给远端（sshd 按客户端请求设置 pty TERM），但远端没有 xterm-kitty 的 terminfo 定义。zsh 5.9 的 zle 行编辑器找不到终端定义，光标定位/行重绘全部退化 → 每次按键重复字符、画面混乱

排查陷阱：远端装了 zsh-autosuggestions，它的补全建议会渲染在当前行后面（如输入 l 显示 lls，其中 s 是建议），capture-pane 会连建议一起抓走，容易误判成"按键重复"。建议用原始字节流（cat -A）对比。

解决方案

在远端安装 xterm-kitty terminfo（本地 kitty 自带，infocmp 导出后远端 tic 导入）：

infocmp xterm-kitty | ssh dev 'tic -x -'

验证：ssh dev 'infocmp xterm-kitty' 有输出即成功。之后输入、退格、方向键、自动补全全部恢复正常。

方案对比与固化

三个层次，按推荐度：

已固化到 dotfiles 仓库 ~/.my_profile.kitty（ssh 包装）：

# 仅"本地有 kitten 且进程确实在 kitty 窗口内(KITTY_PID + KITTY_WINDOW_ID 缺一不可)"才走 kitten ssh, 否则回退普通 ssh
ssh() {
    if command -v kitten >/dev/null 2>&1 \
        && [[ -n "${KITTY_PID:-}" && -n "${KITTY_WINDOW_ID:-}" ]]; then
        command kitten ssh "$@"
    else
        command ssh "$@"
    fi
}
# 备用手动补装: kitty-terminfo <host>; 装依赖: bash dotfiles/run.sh install_kitty [host]

实测细节：kitten ssh 要求"进程确实在 kitty 窗口内"——启动器校验 KITTY_PID + KITTY_WINDOW_ID 两个环境变量（缺一即拒绝："The SSH kitten is meant to run inside a kitty window"），单纯把 TERM 伪装成 xterm-kitty 没用。所以包装必须查这两个变量，tmux 内、其他终端、远端（没装 kitty）自动回退普通 ssh，保证 ssh 永不被包装搞挂。

顺带：服务器不需要装 kitty 也能 ssh 图片预览——只需轻量工具（chafa --format=kitty img 或 viu -k img，apt 安装），渲染由本地 kitty 完成；bash dotfiles/run.sh install_kitty <host> 可一键给远端装 chafa/viu/timg。

问题四：waypipe ssh 后没有 WAYLAND_DISPLAY

现象

waypipe ssh -tY -o controlpath=none dev

连上后 echo $WAYLAND_DISPLAY 为空，而 echo $DISPLAY 正常（localhost:10.0，ssh -Y 的 X11 转发）。运行 Wayland 客户端 weston-dnd 报：

could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'

窗口也没有出现在 host 端。

排查过程

1. waypipe 的代理 socket 确实建了：dev 的 /run/user/1000/ 下能看到一串 wayland-1ET0R84N、wayland-BSpfNUZh 之类的 socket（wayland-<随机后缀> 是 waypipe 的命名规则，时间戳对得上本次会话）
2. 环境变量被 zshrc 清掉了：~/.my_zshrc 里有一段（之前为修 gpg pinentry 问题加的）：

# XDG_SESSION_TYPE=tty（SSH 会话就是这个值）时直接清掉 WAYLAND_DISPLAY
if [ "${XDG_SESSION_TYPE:-}" = "tty" ]; then
  unset WAYLAND_DISPLAY 2>/dev/null
fi

SSH 分配的 pty 会话 XDG_SESSION_TYPE 为 tty，waypipe 给会话设置的 WAYLAND_DISPLAY 被登录 shell 启动时直接 unset 3. weston-dnd 连不上任何合成器：WAYLAND_DISPLAY 为空 → wl_display_connect() 失败 → 窗口根本没创建（哪里都没显示），could not load cursor 是连接失败阶段报的连带错误，随后进程挂起等 Ctrl+C

原 unset 块的来历：tmux server 会继承旧会话的 WAYLAND_DISPLAY（孤儿 socket），残留值让 pinentry-gnome3 误判"有 GUI"而跳过 curses 回退 → SSH 下 gpg 弹窗不出来、干等超时（"agent refused operation"）。相关背景见 GPG 使用指南 的 pinentry 部分。

解决方案

只清掉指向不存在 socket 的残留值，waypipe 创建的真实 socket 予以保留：

if [ "${XDG_SESSION_TYPE:-}" = "tty" ]; then
  if [ -n "${WAYLAND_DISPLAY:-}" ] && { [ -S "${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}" ] || [ -S "${WAYLAND_DISPLAY}" ] || [ -S "/tmp/${WAYLAND_DISPLAY}" ]; }; then
    :
  else
    unset WAYLAND_DISPLAY 2>/dev/null
  fi
fi

（存在多个机器共用 ~/.my_zshrc 的情况，本地与远端同步修改，我这边是符号链接到 dotfiles 仓库，改一处即可。）

验证

之后 waypipe ssh -tY -o controlpath=none dev 再跑 weston-dnd，窗口正常显示在 host 端。

问题五：waypipe ssh 乱码——ssh mux 复用冲突

现象

waypipe ssh -tY douhao 连上后终端输出乱码；同一命令对 dev（命令里带 -o controlpath=none）正常。

排查过程

1. 远端配置全好：douhao 的 .my_zshrc 已是新版（socket 存在性判断）、xterm-kitty terminfo 已装、locale 正常 → 排除配置类原因
2. 怀疑 ssh 复用连接：本地 ssh config 是 ControlMaster auto + ControlPersist 1h，而 douhao 恰好有一条一个多小时前建立、一直活着的 mux master
3. waypipe 内部直接 exec 系统 ssh（strace 实证：PATH 里不存在自定义 ssh，最终落到 /usr/bin/ssh），构造的命令是 ssh -R /tmp/waypipe-server-XXX.sock ... douhao waypipe server ...，不传任何 control 参数 → 走 config 的 ControlMaster auto → 复用别人建的老 master，把 waypipe 的 -R 转发和 X11 附加到既有会话的通道上 → 通道状态不可靠 → 乱码
4. ssh -O exit douhao 清掉旧 master 后再跑 waypipe，恢复正常

解决

• 立即：ssh -O exit <host> 清掉残留 master
• 稳妥：waypipe ssh 固定加 -o controlpath=none（独占连接，waypipe 官方 issue 里 ControlMaster 冲突是已知问题）
• 持久：ssh config 对 waypipe 目标主机关 mux（Host douhao dev 段加 ControlMaster no）——局域网主机 mux 收益≈0

注意

shell 函数/别名（如问题三的 ssh 包装）只拦截交互输入的命令，管不到 waypipe/git/scp 等程序内部对系统 ssh 的调用；这类工具的 ssh 行为只能通过 ssh config（或它们自己的参数）控制。

总结

四个坑点留个备忘：

1. Wayland 下 Alacritty 拖放无解：等 winit 发版 + Alacritty 适配（issue #4010 追踪中），之前别折腾配置
2. WINIT_UNIX_BACKEND 是废弃变量：现代 winit（≥0.29）不认，别信旧教程；强制后端用 env -u WAYLAND_DISPLAY
3. 用户级 desktop 文件覆盖系统级：改名相同即可，update-desktop-database 不用手动跑
4. X11 应用的"字体莫名变大"先查 text-scaling-factor 与 Xft.dpi：GNOME 全局文本缩放会通过 Xft.dpi 传导到 X11 应用，Wayland 应用不受影响，所以只会在 XWayland 场景暴露

代价是 Alacritty 窗口以 XWayland 模式运行（GNOME 下 100% 缩放下无感知差异；高 DPI 缩放下 X11 窗口会模糊，介意的话等上游修复后再切回）。