キーが押されてから受け入れられるまでに遅延があるのはなぜですか？

これは、私がこれまで遭遇した中で最も奇妙で奇妙な問題の1つです。Ubuntu 13.04で昨日まで私のキーボードは完全に正常に動作していました。しかし、今日Ubuntuを起動すると、すべてのキーが機能することが突然わかりますが、キーを押して動作させるには約1秒間押し続ける必要があります。

• この動作はNum Lock、Caps Lockおよびキーを除くすべてのキーに当てはまりScroll Lockます。キーボード上のそれらのインジケータは、それらのキーを押すとすぐに点灯します。

• パスワードを入力するログイン画面でキーボードは正常に機能します。

• 通常のユーザーアカウントの代わりにゲストセッションを使用する場合も、キーボードは正常に機能します。

• キーの再マッピングは行わず、標準の英語（US）キーボードレイアウトを使用しました。

• [システム設定]の[キーボード]の設定をいじりましたが、役に立ちませんでした。

• 私はWindows 7をデュアルブートとして使用しており、キーボードは完全に機能します。

なぜこのような動作に直面しているのですか？これを正規化する方法は？

PS：Logitech Classic Keyboard K100（USBモデル）を使用します。

おそらく、システム設定 → ユニバーサルアクセス → 入力からスローキーオプションを選択したからです。消して：

同様の問題がありました。ここで解決策を試みている間に、私は答えにつまずいた。どういうわけか、スクリーンリーダーがオンになり、不安定な動作を引き起こしていました。[システム設定]→[ユニバーサルアクセス]→[表示]で確認します。スクリーンリーダーがオフに設定されていることを確認します。 スクリーンリーダーオフ

私は画像で適切な答えを投稿することはできません。すべての原因は今のところWindowsのみの公共のコンピューターにいますが、キーボード設定に移動してキー感度設定があるかどうかを確認してから、そこで調整することができます。 ..また、キーボードのプラグを抜いてから再度接続してみてください。これでリセットされるかもしれません...

それが役立つことを願っています...幸運を！

Ubuntuは明らかにWindowsの「スローキー」機能をミラーリングしており、デフォルトではこれを設定しているので、Shiftキーを長押しすると自動的にこの設定がオンになります！

近年、この設定の登場は多くの人々を夢中にさせており、Shift何をタイプするかを考えながら押さえつける習慣は、この設定を誤って簡単にオンにすることを意味します。

受け入れられた答えは、Ubuntuの最新バージョンでは機能しなくなりましたgnome-control-center。もう「スローキー」オプションはありません。

これを確実に無効にする唯一の方法は、コマンドラインを使用することです。

# Get current value of keyboard accessibility (enabled = true , disabled = false)
gsettings get org.gnome.desktop.a11y.keyboard enable
# Get current value of slowkeys-enable
gsettings get org.gnome.desktop.a11y.keyboard slowkeys-enable
# Turn it off!
gsettings set org.gnome.desktop.a11y.keyboard slowkeys-enable false

# Get current value of stickykey-enable
gsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable
# Turn it off!
gsettings set org.gnome.desktop.a11y.keyboard stickykeys-enable false
# Finally, turn the entire keyboard accessibility options off (this should disable the SHIFT key shortcuts)
gsettings get org.gnome.desktop.a11y.keyboard enable false

これは、キーストローク（オンボードなど）をキャッチするデーモンプログラムがある場合に発生する可能性があります。試用版として、gnome-system-monitorbashスクリプトまたは実行中のpythonスクリプトさえあるかどうかを開いて確認してください。オンボードで実行中の場合は閉じてみてください。

私がお勧めするのは、ほとんどの場合、最も簡単でいソリューションです。

.*ディレクトリを別の場所に移動します。

mkdir ~/backup
mv ~/.config ~/.dbus ~/.gconf ~/backup/

セッションを再開します。問題はなくなるはずです。問題が解決した場合は、次の手順で無害なユーザーを1つずつ復元できます。

cp -nr ~/backup/.dbus ~/.dbus

セッションを再開してください、問題は再びありますか？ディレクトリを削除し、代わりにサブディレクトリの内容を1つずつコピーします。他の2つのディレクトリと同じです。

cp -nr ~/backup/.config ~/.config
cp -nr ~/backup/.gconf ~/.gconf

この方法は非常に野tなものであることがわかっていますが、これを引き起こす可能性のある正確なfile / dconf / gconf / xinputが見つからなかったので、ちょっとしたハックで十分です。

キーボードレイアウトの切り替え中に遅延が発生するもう1つの理由があります。問題＃1370953（および＃1370953）によると、このような動作はディスクパフォ​​ーマンスの低下に関連している可能性があります。Maxim Kravetsのコメントを参照してください。

レイアウトが変更されるたびに〜/ .config / dconf / userファイルが変更されます。ディスクがビジーの場合、レイアウトの変更が遅くなります。

ディスクの問題を乗り越えるには、ディスクキュースケジューラを変更することが1つだけではありません。デフォルトでは、Ubuntuはデッドラインスケジューラを使用するように設定されていますが、HDDが遅い場合は、代わりにcfqスケジューラを使用することをお勧めします。

手順を参照してください。

その許容できないテキスト入力遅延の問題は、以前にここで述べたもの（スティッキーキー）とはまったく異なる理由があるかもしれません。

誤って、オプションの「スクリーン拡大鏡」（アクセシビリティオプション）をオンにしました。-そして、私と同じように（ASUS X206HA）低スペックのNetbookを実行している場合、そのことはテキストメッセージの速度を低下させます。-しかし、たまたまこれを見つけて拡大鏡をオフにすると、すべてが再び素早くスムーズに戻りました。

質問で説明したように、ログイン画面では遅延はありませんでしたが、ウィンドウマネージャー（素晴らしいwm）では、不規則なキーボードラグがありました（場合によっては、短い/長い遅延）。以前は、次のコードを/etc/X11/xorg.conf

Section "Device"
Identifier  "Card0"
Driver      "intel"
Option      "Backlight"  "/sys/class/backlight"
EndSection

メイクのxbacklight仕事。私の場合、上記の行がキーボードの遅延を引き起こしたことが判明しました。