web-dev-qa-db-ja.com

LogitechMX3100キーボードを使用したスタックベースのキーボード遅延

LogitechコードレスデスクトップMX31 キーボードをかなり長い間使用しています。たまにタイプミスすることを除いて、私は実際に問題を抱えたことはありません。

しかし、他のどのタイプミスよりもかなり頻繁に、「ロード」ではなく「ロード」というタイプミスをする傾向があることに気づきました。それが私の神経質になり始めたので、私はいくつかのテストをすることに決めました。

私が見つけたのは、小文字の「ロード」を書くときよりも、タイプミスをすることは決してないということでした。すべて大文字、または大文字のLだけで、タイプミスを頻繁に行います。私の実際の（非常に科学的な）テストは、おそらく出力を示すことによって最もよく説明されます：

moatmoatmoat
MoatMoatMoat

loatloatloat
LaotLaotLaot

loafloafloaf
LaofLaofLaof

hoathoathoat
HoatHoatHoat

hoadhoadhoad
HoadHoadHoad

lortlortlort
LrotLrotLrot

私が見つけたのは、シフトが押されたときはいつでも、大文字の「L」を入力すると、次の文字が「o」の場合、他のキーのラグと比較して、大幅なラグが発生するということでした。

High "o" lag:
LoLoLoLoLoLo

No "a" lag:
LaLaLaLaLaLa

No lag for neither "o" nor "a":
lolololololo
lalalalalala

これに気づいたことで、パーキンソン病にかかっていないことを知っていたので、少し正気を取り戻しました。私は実際に正しく入力していました、ラグはそれを間違って解釈しました。

さて、私を本当に悩ませているのは、これがどのように起こっているのか理解できないということです。私が実際に入力しているのは、物理的な順序です。L--o--a --dですが、「a」の前に「o」が押されていても、「a」は「o」の前に出力されます。

したがって、キーボードが「Lo」コンボを処理している間、「a」が優先され、「o」の処理が完了する前に挿入されるため、LoadではなくLaodになります。また、これは「Lo」と入力した場合にのみ発生し、小文字の「lo」と入力した場合には発生しません。

この問題は、キーボードハードウェア、レシーバーハードウェア、またはキーボードソフトウェアドライバーが原因である可能性があります。ただし、障害の場所に関係なく、これをFIFOキュー以外のものとして実装する方法を想像することはできません。一般的な遅延は確かに、私はそうなるでしょうが、それで生きることができます。イライラしますが、ラグはさまざまなキーに異なる影響を与え、予測できない結果をもたらすことさえあります-それはまったく意味がありません。

有線キーボードに切り替えるだけで問題は解決しました。しかし、私はそれを振り払うことはできません。どのようなバグ/エラー/シナリオがこのようなケースになりますか？

編集：私はレッドブルを飲むのをやめて、代わりに水に固執することが提案されました。それは実際に問題を解決するのに役立つかもしれませんが、私は実際にはそのような解決策を探していません。この動作を引き起こす可能性のある実行可能な技術的解決策を想像できないため、これがどのように発生するかについての説明にもっと興味があります。

lagdelaywireless-keyboardlogitech-keyboard
6
Mark S. Rasmussen

頭に浮かぶのは、ワイヤレスキーボードが送信するキーコードとそれに伴う遅延を参照することです。

キーを押すたびに、DOWNコードとUPコードの両方が送信されます。

  • Shiftキーを押すと、「SHIFT-DOWN」が送信されます。
  • 'l'を押し、 'l-DOWN'を送信します
  • 'l'をリリースし、 'l-UP'を送信します
  • sHIFTを放し、「SHIFT-UP」を送信します
  • 'o'を押し、 'o-DOWN'を送信します
  • 'o'をリリースし、 'o-UP'を送信します
  • 'a'を押し、 'a-DOWN'を送信します
  • 'a'をリリースし、 'a-UP'を送信します
  • ... 等々

Logitechワイヤレスは、シフトストローク（または「モディファイア」ストローク... ctrl、shift、alt ..）の送信中に何か影響を及ぼしているようです。

私はLogitechワイヤレスキーボード（モデルK270）を持っていて、このようなものに気づいていませんが、自分のタイピングスタイルから、「make」を「maek」および「mkae」と誤って入力することがよくあります...それは私です、私はコードを書くすべてのキーボードとコンピューターで一貫性があります...そのため、bashとvimにエイリアスを追加して、これを行うたびに（比喩的に）頭を打たれることがないようにしました。

それは目に見えるまたは知覚できる遅れですか？あなたのタイピング速度に基づいてのみ起こりますか？

私はここでショットガンのアイデアに行きます：私が考えることができるランダムなものは関連するかもしれません...

  • 送信されたその特定のビットパターンのワイヤレス干渉の可能性はありますか？ワイヤレスをレシーバーに再同期してみましたか？
  • 「L」と「O」は通常同じ「列」行にあるため、キーとマトリックスの干渉の可能性はありますか？ （行かもしれません...しかし、あなたは考えを理解します）
  • あなたは非常にまれで、おそらく致命的な「L-a-o」ウイルスを持っています。 （聞いたことがありませんか？珍しいと言いました...）

キーボードをレシーバーに再同期してみます。いいえ、どちらの方法もわかりませんが、奇妙なことはあまり効果がありません。痛くない？正しい？

1
lornix

普段はコメントで書いているのですが、評判が悪いので、なるべく参考にさせていただきます。

遅延がOMの組み合わせによるものであることを除いて、非常によく似た問題があります。

（データベースクエリで）FROMと書くことがあり、SPACEBARストロークが最初に処理され、最終的にFROになります。私のMが実際に発生することはないので、まったく同じ問題ではありませんが、非常に似ています。また、SHIFTを保持している場合にのみ実行されます。代わりにCAPSLOCKを使用している場合、遅延はありません。または、CAPSLOCKが有効になっていて、SHIFTを押したままにすると、小文字のoとmによって同じ遅延が発生します。問題は間違いなくSHIFTにあります。

私はロジクールキーボードも持っていますが、それはG110であり、有線です。

特定のシナリオをテストしたところ、問題はありません。したがって、各キーボードモデル（または対応するドライバー）には独自の不整合があり、何らかの理由で、キーストロークのキューが適切に更新されない必要があります。 （あなたがそれがキューであると言ったように、そして私はなぜそうしないのか分かりません）。

0
Tiberiu