![如何识别负责重新排序键盘输入的组件?](https://linux22.com/image/1127215/%E5%A6%82%E4%BD%95%E8%AF%86%E5%88%AB%E8%B4%9F%E8%B4%A3%E9%87%8D%E6%96%B0%E6%8E%92%E5%BA%8F%E9%94%AE%E7%9B%98%E8%BE%93%E5%85%A5%E7%9A%84%E7%BB%84%E4%BB%B6%EF%BC%9F.png)
我在一台 Dell Latitude 13 笔记本电脑上运行着 Ubuntu 14.04。当我启动 Chromium 并在不同的选项卡中打开来自 stackexchange 的多个页面时。我输入的任何文本都会经常出现字符以与输入顺序不同的顺序显示的现象。例如,这一段实际上显示为:
我在一台戴尔 Latitude 13 笔记本电脑上运行着 Ubuntu 14.04。当我打开 Chormium 时,我打开了几个页面,并切换到不同的选项卡。我输入的任何文本都会以不同的格式显示字符。例如,这篇文章实际上显示为
你可以想象,每次发生这种情况时都必须手动修复,这非常令人沮丧。这种行为看起来就像软件堆栈中的某个层将按键插入堆栈而不是队列中,如果按键没有在到达时尽快被使用,它们就会以错误的顺序显示。
这种情况偶尔会发生,当 Chromium 进行大量交换时,这种情况似乎更常发生。我无法确定软件堆栈的哪一层导致了这个问题。我是否可以启用其他调试/日志功能来显示字符在软件堆栈的不同层中出现的顺序?
到目前为止我尝试过
通过向 xterm 发送交替STOP
和CONT
信号,我能够减慢 xterm 的速度,刚好足以重现症状。由于即使 xterm 暂时冻结,键盘输入的重新排序也不应该发生,因此我认为可以肯定地得出结论,该缺陷不是出在 Chromium 或 stackexchange 中,而是出在涉及这两种情况的某些软件中。
为了排除键盘硬件缺陷的可能性,我使用模拟按键进行了测试。
sleep 10 ; for K in {a..z} ; do xdotool type "$K" ; sleep 0.2 ; done
使用该命令,我能够重现该问题。有一次,按键按顺序显示abcdefghlmkjpnioqrstuvwxyz
。因此,当它也发生在由 生成的按键上时xdotool
,这不可能是键盘或键盘控制器的缺陷。
如果我进一步加快使用 xdotool 产生的输入速度,就会导致 xterm 锁定。
我看到 xterm 在键盘输入快速到达时锁定,即使没有使用 STOP 信号人为减慢速度,也是如此。当我看到 xterm 像这样锁定时,通常在我终止 xterm 并启动一个新 xterm 后,这种情况仍然会发生。这个问题一直存在,直到我运行compiz --replace
。运行该命令后,一切都运行得更快,至少在最初几天,xterm 不再锁定。
因此,有证据表明这两个问题是相关的并且有某种联系compiz
,但我没有任何确凿的证据来支持这种怀疑。