Ubuntu 22.04 有线键盘偶发按键无响应：从硬件嫌疑到 IBus 超时

问题现象

在 Ubuntu 22.04 上遇到一个挺烦人的问题：有线键盘会偶发性按键无响应，过一会儿又自己好了。频率不低，但没有固定触发条件，也找不到规律。

这种”偶现 + 自愈”的问题最容易让人误判为硬件接触不良——毕竟”时好时坏”听起来太像接触问题了。

结论先行

先把结果放在前面，急着解决问题的话看这里就够了：

根因：不是键盘坏了，也不是 USB 问题，而是输入法框架 IBus 在处理键盘事件时超时卡住
关键判据：故障发生时用 evtest 观察，按键事件依然正常产生 —— 说明信号已到内核，卡在了上层
有效解法：换用 fcitx5 替代 IBus（重置 IBus 配置无效）
应急手段：故障时手动切换一次输入法，立刻恢复

下面是完整的排查过程。

排查思路：从下往上逐层排除

键盘输入要经过 硬件 → USB → 内核输入子系统 → 输入法框架 → 应用这条链路。偶发故障最有效的办法是从最底层开始逐层排除，确认每一层是否正常。

第一层：硬件与 USB

先排除最物理的因素：

换 USB 端口：把键盘插到主板后置的其他 USB 口。机箱前置面板的 USB 可能供电不稳或接触不良。
不经过 USB 集线器：直连主板端口，排除 hub 供电/转接问题。
换键盘测试：拿另一个确认正常的有线键盘替换。如果新键盘也出现同样现象，说明问题不在键盘。
交叉验证：把原键盘接到另一台电脑上。如果在别的机器上一切正常，就说明问题集中在这台 Ubuntu 系统的软件层。

结论：换端口、换键盘、交叉验证都没能复现或消除问题 → 硬件基本无罪。

第二层：内核日志

看内核有没有 USB 层面的报错：

sudo dmesg -T | tail -50

重点找 usb、input、hid 关键词附近的 Error / Warning，尤其这几类典型错误：

reset low-speed USB device —— USB 设备被重置
device descriptor read/64, error -110 —— USB 通信超时
error -71 —— 协议错误

结果：内核日志里没有任何相关报错。这个”没有”很关键——说明不是驱动崩溃或 USB 掉线级别的问题，故障发生在更上层。

同时开一个终端实时盯着系统日志，等故障出现的瞬间看有没有异常：

journalctl -f

第三层：输入设备事件

内核没报错，那内核到底还在不在收键盘事件？用 evtest 直接监听输入设备：

sudo apt install evtest
evtest

运行后选择键盘对应的设备编号，正常按键会实时打印事件流。

这一步是整个排查的分水岭，判断逻辑很清晰：

故障时 evtest 没有事件输出 → 问题在硬件或驱动层
故障时 evtest 仍有事件输出 → 内核收得到按键，问题在更上层（输入法框架或桌面环境）

实测结果：键盘”失灵”时，evtest 输出完全正常，每次按键都有事件。也就是说按键信号已经正确到达内核，只是没能传递到应用程序。

与此同时，系统日志在故障瞬间出现了 IBus 相关的超时报错（大意是 IBus 在处理输入法事件时等待超时、请求未能在预期时间内完成）。两条证据一对上，根因就明确了。

根本原因：IBus 处理键盘事件超时

链路是这样的：

所有图形应用  →  IBus 输入法框架  →  键盘驱动
     ↑                  ↓
 (输入请求)      (IBus 超时 / 卡住)
     ↑                  ↓
        用户感觉「输入没反应」

按键信号本身没丢，是中间的 IBus 卡住了，导致上层应用拿不到输入，用户体验就是”键盘失灵”。IBus 自己恢复后，键盘又能用了——这解释了为什么故障会”自愈”。

顺便说清楚 IBus 是什么

IBus（Intelligent Input Bus）是 Linux 上的输入法框架，主要负责：

管理多种输入法：在拼音、五笔、日文、韩文等之间切换
处理复杂字符输入：把简单按键转换成汉字、假名等
统一输入接口：为所有应用提供一致的文本输入入口

打个比方，IBus 像个翻译官：你敲 wo ai ni，IBus 认出这是拼音、转换成「我爱你」，再把结果交给应用程序。

问题就在于——所有键盘输入都要过它这一道。它一卡，整个桌面的输入都受影响，哪怕你只是在敲英文。

还要区分两个容易混淆的概念：

输入法框架 (IBus / fcitx5)  ←调用→  输入法引擎 (如 Intelligent-Pinyin)
        ↓                                    ↓
     系统集成层                          具体的输入逻辑

框架负责和系统、应用打交道；引擎负责”拼音怎么变成汉字”这类具体转换逻辑。这次出问题的是框架这一层。

解决方案及实际效果

试了几个方向，效果差异很大，按实际结果排列。

方案一：重置 IBus 配置（实测无效）

先试最轻量的办法，把 IBus 配置清掉重启：

killall ibus-daemon
rm -rf ~/.config/ibus
ibus-daemon -drx

结果：没用。 故障照旧出现，说明不是配置文件损坏导致的。

方案二：换掉输入法框架（推荐）

既然是 IBus 框架本身卡，那就换一个更稳定的实现——fcitx5：

# 安装 fcitx5 及中文输入支持
sudo apt update
sudo apt install fcitx5 fcitx5-chinese-addons fcitx5-config-qt

# 设置为默认输入法框架
im-config -n fcitx5

# 停掉 IBus，启动 fcitx5
killall ibus-daemon
fcitx5 -d

改完注销重新登录（或直接重启）让框架切换彻底生效。这是最根治的做法。

注意包名是 fcitx5 而不是 fcit5，中文输入用 fcitx5-chinese-addons。

方案三：排查系统资源占用

如果怀疑 IBus 是被资源问题拖慢的，可以看看它的占用情况：

# 只看 ibus-daemon 这个进程的 CPU / 内存占用
top -p $(pgrep ibus-daemon)

# 更直观的交互式进程查看器
htop

top -p <PID> 会盯住指定进程，显示它的 CPU、内存占用。htop 比 top 更可视化，能排序、搜索、看进程树，适合整体看系统负载有没有异常。

方案四：升级或重装 IBus

如果不想换框架，可以先试试升级/重装，可能命中已修复的 bug：

# 更新系统
sudo apt update && sudo apt upgrade

# 或者重装 IBus 相关包
sudo apt install --reinstall ibus ibus-gtk ibus-gtk3

方案五：应急手段——切一下输入法

故障发生时，手动切换一次输入法往往能立刻恢复输入。这算不上修复，但作为临时救急很实用（不用重启，不用等它自己好）。

这个现象在 ibus-libpinyin 的 issue 里也有人反馈过，属于已知的框架层问题。

小结

几点值得记下来的经验：

“日志里什么都没有”也是有效信息。 内核日志干净，直接排除了驱动崩溃和 USB 掉线，把范围推到上层。
evtest 是分水岭工具。 故障时事件流是否正常，一刀切开”硬件/驱动层”和”框架/应用层”两种可能，比反复换硬件高效得多。
偶发 + 自愈，优先怀疑中间件而不是硬件。 硬件接触不良通常伴随内核报错；能自己恢复的，多半是某个服务卡住又缓过来了。
表象和根因可以隔得很远。 现象是”键盘坏了”，根因却在输入法框架——中间隔着好几层。顺着链路逐层验证，比凭直觉猜要可靠。