我在 Dell Latitude 13 筆記型電腦上運行 Ubuntu 14.04。當我啟動 Chromium 並在不同選項卡中從 stackexchange 開啟多個頁面時。我輸入的任何文字通常會以與輸入時不同的順序顯示字元。例如，這一段實際上顯示為：
我在 Dell Latitude 1 3 筆記型電腦上運行 Ubuntu 14.04。當我打開 Chormium na dopne 時，有幾個頁面形成了不同的選項卡。我輸入的任何文字都會以不同的形式顯示字元。對於 exmapel，這個 apragraph 實際上顯示為
正如您可以想像的那樣，每次發生這種情況都必須手動修復，這可能會非常令人沮喪。該行為看起來好像軟體堆疊中的某些層正在將按鍵插入堆疊而不是佇列中，如果它們到達時沒有盡快被消耗，它們就會以錯誤的順序顯示。
這種情況只會偶爾發生，而且當 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 鎖定。
當鍵盤輸入快速到達時，即使沒有使用 STOP 訊號人為地減慢輸入速度，我也看到過 xterm 鎖定的情況。當我確實看到 xterm 像這樣鎖定時，通常在我殺死 xterm 並啟動一個新的 xterm 後，它就會繼續發生。這個問題一直存在，直到我運行compiz --replace。運行該命令後，一切都運行得更快，並且 xterm 至少在最初幾天不再鎖定。
因此，有一些證據表明這兩個問題是相關的，並且在某種程度上與 相關compiz，但我沒有任何確鑿的證據來支持這一懷疑。