Barrier: スーパーキー（Windowsキー）がクライアントで「押された」状態でスタックする

Linuxサーバー-> Linuxクライアント（両方ともArch）でもこの問題が発生します。 多くの場合、スタックしたスーパー/メタキーですが、他の修飾子（shiftまたはctrl）の場合もあります。 問題が発生した場合（この例ではシフトとしましょう）、バリアサーバーを再起動し、クライアントマシンに切り替えても、問題はありません。 すぐにホストに切り替えてからクライアントに戻すと、Shiftキーが再びスタックします。 モディファイアは、クライアントマシンの物理キーボードにも「スタック」したままです。 これを解決する一般的な方法は、クライアントマシンを再起動することです。

これをデバッグするのにどのように役立つかについてのアドバイスは、私を完全に狂わせているので、ありがたいです。 クライアントマシンにSSHで接続できます。 DISPLAY=:0 xset -qとDISPLAY=:0 xevをデバッグしようとしましたが、すべてが正常に見えます（xsetで保持されている修飾子が表示されず、クライアントで「正しい」キーが（バリアを介してまたは直接）押されています。

この問題は、バリア2.2.0とシナジー1.10.1を使用した場合に発生します。

私もこれを実質的に毎日取得しています。 クライアントとサーバーの両方でArchLinux（最近更新）を実行しています。 この問題は主にクライアントに影響を与えるようであり、Joshと同様に、クライアントマシンのバリアを解除した後も問題が続きます。

この問題を解決するには、（TTYに）ログアウトし、再度ログインしてXを再起動する必要があります。

これはWindowsクライアントにとっても問題であり、いくつかの異なる修飾キーがスタックする可能性があると思います。 誰かがそれを確実に再現できれば、それは役に立ちます。

私にとっては、Altキーになる傾向があります。 Altを使用してウィンドウの移動とサイズ変更（Alt +ドラッグ）を行うように環境を構成しました。 ウィンドウを画面の端（通常はマウスをホストコンピューターに戻すことができる端）にAltキーを押しながらドラッグすると、トリガーされる可能性があります。 ウィンドウを動かしているときは目を離さず、それが何か関係があるかどうかを確認します（マウスがデバイス間を移動するときにモディファイアが保持されます）。

ubuntuサーバーとWindowsクライアントを使用してメタキーがスタックしています。 最初、メタキーはubuntuでのみ機能し、その後はどちらでも機能しません。

この問題を修正するのに役立つ可能性のあるデバッグや提供できるログはありますか？ キーボードを毎日動作させるためだけにXウィンドウセッション全体を閉じなければならないことは持続可能ではなく、問題は悪化しているように思われるため、この時点で別のものに切り替えることを検討しています。

提供できるものがあれば、この問題は1日に1回確実に発生するため、データを非常に迅速かつ繰り返し提供できます。

@ DarwinSurvivor-これを（Xを残さずに）「リセット」することがわかったのは次のことだけです...そしてそれは（まったく）理想的ではありません：

#!/usr/bin/env bash

setxkbmap -layout us
xdotool keyup Shift_L Shift_R Control_L Control_R Alt_L Alt_R Super_L Super_R Hyper_L Hyper_R Caps_Lock 204 205 206 207

私は今、これが何らかの形で非修飾子に影響を与えています。

たとえば、私はcVimを使用しているので、「x」は「Ctrl + F4」と同等であり、現在のタブを閉じます。 xキーが動かなくなってしまいました。つまり、Chromeウィンドウに切り替えると、ウィンドウ全体が消えるまで、ラピッドファイラーがすべてのタブを閉じます。

私のスーパーキーは時々このように立ち往生します。 DarwinSurvivorが述べたように、xのような他のキーもスタックする可能性がありますが、これらのキーは、私のマシンでは常に1〜2秒後に正しく動作します。 クライアントが「xxxxxxxxx」をマッシュアウトして停止する間、カーソルもフリーズするため、これは（wi-fi）ラグが原因であると推測しました。 ただし、Xの再起動/再起動以外では、スーパーキーの問題はほぼ永続的なようです。

サーバー：Windows 10
クライアント：Linux Mint 19.1 Cinnamon

Altキーでも同じようになります。

動作は逆になります。 ホストでAltキーを押すと、クライアントは押されていないように動作します。 それはすでに二度起こった。 何が最初にそれを修正したのかわかりません。

サーバー：Windows 10
クライアント：macOS High Sierra 10.13.6

*更新：
ALTキーが動かなくなったら、CONTROLキーを押して解決できます。

MacOSホストとLinuxMintクライアントでも同じことが起こります（スーパーキーが動かなくなる、場合によってはCtrlキー）。

これは、原因不明で断続的に発生しますが、ヘッドセットを使用してSkypeまたはGoogleハングアウトを使用している場合によく発生します。 Xの再起動が役立つ場合があることを解決するには、完全なシャットダウン/再起動が必要な場合があります。 setxkbmap / xdotoolがリセットされていないようです。

サーバー：macOS High Sierra 10.13.6
クライアント：Linux Mint 18.3
ネットワーク：同じスイッチ、同じサブネットへのLAN接続（Wifiなし）
バリア2.3.2-リリース-210c2b70

バリアでは、クライアントでメタキーが「押される」原因は何ですか？ 状態の変化を引き起こし、それがリセットされないようにする何らかのイベントがあるに違いありません、私はおそらく素朴に推測します。

Shiftキーがクライアントから解放されない場合の同じ問題。 スーパーキーよりも多くの修飾子に影響するように見えるので、タイトルの名前を変更します。

オペレーティングシステム
サーバー：Ubuntu 18.04（カーネル4.15.0-99-汎用）
クライアント：Ubuntu 18.04（カーネル5.3.0-51-汎用）

バリアバージョン
サーバー：barrierc 2.3.2-13-g9080ce45
クライアント：バリア2.3.2-13-g9080ce45

Synergyhttps ：//github.com/symless/synergy-core/issues/6459で同様の問題が見つかりました

明確にするための小さな更新ですが、Shiftキーを押すたびにリリースされていないキーが発生するため、ネットワークの問題が原因である可能性はほとんどありません。

サーバー：バリア2.3.2-スナップショット-210c2b70（Windows 10 1909）
クライアント：バリア2.3.2-RELEASE-00000000（Arch Linuxは最新、Mate 1.24 over Xorg）

同じように、CTRLクライアントがクライアントでスタックし、クライアントでCTRL-ALT-DELを押すと、サーバー（Windows）（Lock | SwitchUser | Sign Out | Task Manager）メニューが呼び出され、ESCでデスクトップに戻り、クライアントでCTRLがスタック解除されます。数秒（最大で20秒）、その後、それ自体で再びスタックします。

クライアントとサーバーの両方のDebug2レベルのログには、「画面の開始/終了」メッセージだけが表示されます。

バグは、Ctrlの関与により、単純なキーストロークをコマンドとして解釈するため、クライアントをかなり使用できなくします。

私もこれを経験しており、クライアントのctrlキーとaltキーの両方がスタックしています。
クライアントとサーバーはどちらもUbuntuであり、どちらもバージョン2.3.2-snapshot-9080ce45です。

Debian 2.1.2 + dfsg-1
クライアントでShiftキーを押すと、Shiftキーを押したままにしない限り、他のキーが機能しなくなります。 たとえば、Lを入力した後は、他の大文字しか入力できません。
ポインタをサーバーに戻し、次にクライアントに戻すと、ポインタがリセットされます。

バリア2.3.3を搭載した2台のLinuxMint（20および19）コンピューター間で定期的に発生します。

SHIFT_Rというラベルの付いた右のShiftキーが動かなくなっていることがわかります。
キーを押す/離すだけで問題が解決します。

スタックキーは次の方法で検出できます： xev | grep 'keycode .* (.*)'

以前のコメントに加えて、これはLinuxクライアントで次のアクティビティのいずれかに関連して頻繁に発生します。

• 高速ウィンドウスイッチ（たとえば、alt-tab、高速シーケンスで押されます。つまり、alt-tab-tab-tabではなくalt-tab / alt-tab / alt tab）。 これは断続的です
• Zoom、Skype、ハングアウトなどのオーディオまたはビデオチャットアプリを使用します。 これは、たとえば7/10の場合にかなり予測可能です
• （イーサネットの代わりに）wifi経由でネットワークに接続されている
• Wi-Fi接続からイーサネットへの切り替え。 8/10の場合はかなり予測可能です。

キーがストックされると（私にとってはCtrlキーです）、新しいターミナルウィンドウにランダムな文字を入力できない、キャップがない、キーボード入力がまったくないなど、他の症状が数秒から数分後に現れ始めます。 通常、状況は悪化し、唯一の解決策は再起動することです。

また、これらのアクティビティがない場合もありますが、まれにしか発生しないことに注意してください。

クライアント：
Linux 4.15.0-107-generic＃108〜16.04.1-Ubuntu SMP Fri Jun 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
バリア2.3.2-スナップショット-210cb270
ビルド日：2020年6月5日金曜日

サーバ：
Darwin 17.7.0 Darwinカーネルバージョン17.7.0：5月27日水曜日17:00:02 PDT 2020; ルート：xnu4570.71.80.1〜1 / RELEASE_X86_64 x86_64
バリア：2.3.2-リリース-210cb270
ビルド日：2019年10月3日

ネットワーク：イーサネット、1 GB、同じサブネット、場合によってはWi-Fi（バリアとクライアントは同じルーター上にありますが、サーバーはイーサネット経由で接続され、クライアントはWi-Fi経由で接続されます）

更新しました

2020年8月26日-周波数への貢献者としてwifi接続を追加
2020年8月28日-周波数への貢献者としてイーサネットスイッチにwifiを追加

今日この問題に遭遇したとき、私はそれをかなり定期的に再現できると思います。 正確なステップを絞り込もうとしています。

私がこれまでに持っているのはこれです：

1. クライアントでバリアを開始するためのショートカットを割り当てます（私はCTRL-ALT-SHIFT-F9を使用しました）
2. クライアントに直接接続されたセカンダリキーボードでショートカットを使用してバリアを開始します（これまでは実行されていなかったことに注意してください）
3. サーバーに接続されたプライマリキーボードを使用して、画面をクライアントに切り替えます（バリアショートカット、CTRL-ALT-SHIFT-F12を使用）
4. サーバーキーボードの修飾キーを押します（実際には必要ありませんが、xkbwatchが更新されます）

Linuxクライアントで、少なくとも1つの時点で、複数のバリアプロセス（バリアcではなくバリア）が実行されていることがわかりました。 すべてを新しく再起動して、問題をきれいに再現する一連の手順を絞り込むことができるかどうかを確認します。

OK、私はそれをさらにテストしました問題を確実に再現します。

Client and Server in this case refer to barrier setup only.
Linux server has a secondary pair of keyboard+mouse.
Primary keyboard and mouse are connected to windows machine.
Except where noted, all operations are performed on the primary keyboard + mouse

1. Reboot both Linux Client and Window Server machines
2. Login to Linux (using secondary keyboard + mouse)
3. Login to Windows
4. SSH into Linux from Windows
  - "ps axu | grep -i barrier"
  - No barrier processes running
5. DISPLAY=:1 xkbwatch &
6. On secondary keyboard, press and release each modifier key, one at a time, and confirm xkbwatch shows them correctly
  - Also note the "super" key notably does it's normal action
7. On secondary keyboard, press CTRL-ALT-SHIFT-F9 shortcut to run barrier
  - "ps axu | grep -i barrier"
  - Output shows "barrier" and "/usr/bin/barrierc ..." both running
8. On secondary keyboard, again press and release each modifier key (SUCCESS)
9. Start Barrier Server on Windows machine
10. On secondary keyboard, again press and release each modifier key again (SUCCESS)
11. Switch primary keyboard to Linux screen by pressing CTRL-ALT-SHIFT-F12 shortcut
12. Press and release CTRL then ALT (FAIL)
  *** At this time, the xkbwatch window shows modifiers stuck for ALT and CTRL
13. Switch primary keyboard to Windows screen by pressing CTRL-ALT-SHIFT-F12 shortcut
14. On secondary keyboard, again press and release each modifier key again - modifiers rest correctly (SUCCESS)
15. Kill "barrier" and "barrierc" processing on the Linux client
16. On secondary keyboard, press CTRL-ALT-SHIFT-F9 shortcut to run barrier again
17. On secondary keyboard, again press and release each modifier key again (SUCCESS)
18. Switch primary keyboard back to Linux screen by pressing CTRL-ALT-SHIFT-F12 shortcut
19. Press ALT key on primary keyboard
  * CTRL and SHIFT key modifiers are now stuck
20. Switch primary keyboard back to Windows screen by pressing CTRL-ALT-SHIFT-F12 shortcut again
21. On secondary keyboard, again press and release each modifier key again - modifiers stay stuck this time (FAIL)

これを注意深く読むと、1回は回復できたが、2回目は回復しなかったことがわかります。

奇妙なことに、この試みではCTRLキーとSHIFTキーが動かなくなったにもかかわらず、それをトリガーしているように見えるのはALTキーです。 また、 xdotoolを使用して修飾子をリセットしても機能することがわかりましたが、上記の@joshskidmoreからコピーした次のコマンドラインを使用するまで、ALTをクリアするのに問題がありました。スタックした修飾子によりubuntuマシンで直接コマンドを実行できなくなるため、SSH経由でログインしてこれを実行します）：

xdotool keyup Shift_L Shift_R Control_L Control_R Alt_L Alt_R Super_L Super_R Hyper_L Hyper_R Caps_Lock 204 205 206 207

ありがとう@joshskidmore！

また、今回は、Linuxクライアントで重複するバリアプロセスが検出されなかったことにも注意してください。

別のデータポイント：SSHを使用してLinuxマシンにログインし、バリアを開始すると、問題は発生しません。

うーん、そして別のデータポイント：SSHを使用してLinuxマシンにログインし、バリアを開始します。セカンダリUSBキーボード（Linuxマシンに直接接続されている）でCTRL-ALT-SHIFTを押しながら、問題を再現します。

これで、問題を確実に再現できます。

1. Linuxクライアント（ラップトップ）、macosサーバー-クライアントはサーバー（LANネットワーク）に正常に接続されています。 どんな時間でも問題なく動作します
2. 移動中のラップトップのホットプラグを抜きます。 ある時点でwifiをオンにして、組み込みのキーボードとマウスで直接作業します（つまり、バリアサーバーへの接続は不可能で、ネットワークが異なります）
3. ドッキングステーションに再度接続します。Wi-Fiはオンのままで、バリアはサーバーに正常に接続します
4. 数回のキーストロークとマウスクリックで、奇妙なことが起こり始めます。 Ctrlキーが動かなくなった。 入力すると、ウィンドウが自由に閉じたり開いたりします（おそらく、Ctrlキーとキーの組み合わせ）。マウスをクリックしても、期待どおりの結果が得られません（たとえば、Chromeでウィンドウを閉じたり新しいタブを開いたりすることはできません）。

再起動するだけで問題は解決します。

注：これは、バリアが実行されていない場合は発生しません。 Linux /ハードウェアの問題ではないと結論付けました。

クライアント：
Linux 4.15.0-107-generic＃108〜16.04.1-Ubuntu SMP Fri Jun 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
バリア2.3.2-スナップショット-210cb270
ビルド日：2020年6月5日金曜日

サーバ：
Darwin 17.7.0 Darwinカーネルバージョン17.7.0：5月27日水曜日17:00:02 PDT 2020; ルート：xnu4570.71.80.1〜1 / RELEASE_X86_64 x86_64
バリア：2.3.2-リリース-210cb270
ビルド日：2019年10月3日

それが私に起こったとき、私は何も差し込んだり抜いたりしていませんでした。 両方のラップトップはずっとWiFiを使用していました（私が気付いていないサイレント切断と再接続があった場合を除きますが、サイレント切断を疑う理由はありません。

私はあなたと同じ問題を抱えており、バリアを使用できなくしています...： '（