Barrier: Die Supertaste (Windows-Taste) bleibt auf dem Client "gedrückt"

Ich habe auch dieses Problem mit Linux Server -> Linux Client (beide Arch). Es ist oft ein festsitzender Super- / Meta-Schlüssel, aber gelegentlich auch andere Modifikatoren (Shift oder Strg). Wenn ich das Problem habe (sagen wir, die Verschiebung für dieses Beispiel), wenn ich den Barrier-Server neu starte, zurück zum Client-Computer wechsle, sind die Dinge normal. Wenn ich sofort wieder zum Host und dann zurück zum Client wechsle, bleibt die Umschalttaste wieder hängen. Der Modifikator bleibt auch auf der physischen Tastatur des Client-Computers "hängen". Der typische Weg, dies zu beheben, besteht darin, den Client-Computer neu zu starten.

Jeder Rat, wie ich beim Debuggen helfen könnte, wäre dankbar, da er mich absolut verrückt macht. Ich kann SSH in den Client-Computer. Ich habe versucht, DISPLAY=:0 xset -q und DISPLAY=:0 xev zu debuggen, und alles scheint normal zu sein (mit xset werden keine gehaltenen Modifikatoren angezeigt und die "richtigen" Tasten werden (über barriere oder direkt) auf dem Client gedrückt.

Dieses Problem besteht bei Verwendung von Barrier 2.2.0 sowie Synergy 1.10.1.

Ich bekomme das auch praktisch täglich. Ich verwende Arch Linux (kürzlich aktualisiert) sowohl auf dem Client als auch auf dem Server. Das Problem scheint in erster Linie den Client zu betreffen und setzt sich wie Josh auch nach dem Abbau der Barriere auf dem Client-Computer fort.

Um das Problem zu beheben, muss ich mich abmelden (bei meinem TTY), wieder anmelden und X neu starten.

Ich denke, dass dies auch für Windows-Clients ein Problem ist und dass mehrere verschiedene Modifikatortasten stecken bleiben können. Wenn jemand es zuverlässig reproduzieren kann, wäre das hilfreich.

Für mich ist es eher die Alt-Taste. Ich habe meine Umgebung so konfiguriert, dass Alt zum Verschieben und Ändern der Fenstergröße verwendet wird (Alt + Ziehen). Es ist möglich, dass es ausgelöst wird, wenn ich ein Fenster bei gedrückter Alt-Taste an den Bildschirmrand ziehe (der Rand, an dem sich meine Maus normalerweise zum Host-Computer zurückbewegen kann). Ich werde ein Auge auf mich haben, wenn ich Fenster bewege, und sehen, ob das etwas damit zu tun hat (der Modifikator wird gedrückt, wenn sich die Maus zwischen Geräten bewegt).

Ich habe einen Meta-Schlüssel mit Ubuntu-Server und Windows-Client stecken. Zuerst funktioniert der Metaschlüssel nur für Ubuntu und dann auch nicht für beide.

Gibt es Debugging oder Protokolle, die wir bereitstellen können, um dieses Problem zu beheben? An diesem Punkt denke ich darüber nach, zu etwas anderem zu wechseln, da es nicht nachhaltig ist, meine gesamte X-Window-Sitzung zu schließen, damit meine Tastatur täglich funktioniert, und das Problem sich zu verschlimmern scheint.

Wenn ich etwas bereitstellen kann, tritt dieses Problem jetzt zuverlässig einmal am Tag auf, sodass ich Daten sehr schnell und wiederholt bereitstellen kann.

@DarwinSurvivor - Das einzige, was ich gefunden habe, um dies "zurückzusetzen" (ohne X zu verlassen), ist das Folgende ... und es ist (überhaupt) nicht ideal:

#!/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

Ich hatte jetzt irgendwie diesen Effekt Nicht-Modifikatoren.

Zum Beispiel verwende ich cVim, also entspricht "x" "Strg + F4" und schließt die aktuelle Registerkarte. Die x-Taste blieb hängen, was bedeutet, dass beim Wechseln zu einem Chrome-Fenster alle meine Registerkarten geschlossen werden, bis das gesamte Fenster verschwindet.

Mein Superschlüssel bleibt manchmal so hängen. Andere Schlüssel wie x können ebenfalls stecken bleiben, wie DarwinSurvivor erwähnt hat, obwohl sich diese Schlüssel nach ein oder zwei Sekunden auf meinem Computer immer wieder selbst korrigieren. Ich nahm an, dass dies durch eine (Wi-Fi) Verzögerung verursacht wurde, da mein Cursor ebenfalls einfriert, während der Client 'xxxxxxxxx' drückt und dann stoppt. Das Super-Key-Problem scheint jedoch fast permanent zu sein, abgesehen vom Neustart von X / Neustart.

Server: Windows 10
Client: Linux Mint 19.1 Cinnamon

Ich bekomme das gleiche mit der ALT-Taste.

Das Verhalten wird umgekehrt. Wenn ich die Alt-Taste auf dem Host drücke, verhält sich der Client so, als wäre er nicht gedrückt. Es ist schon zweimal passiert. Ich bin mir nicht sicher, was das erste Mal behoben hat.

Server: Windows 10
Client: macOS High Sierra 10.13.6

*aktualisieren:
Wenn die ALT-Taste hängen bleibt, kann ich die CONTROL-Taste drücken, um sie zu beheben.

Ich erlebe dasselbe (Super-Key steckt fest, manchmal die Strg-Taste) mit einem MacOS-Host und einem Linux Mint-Client.

Dies geschieht zeitweise ohne bekannte Ursache, obwohl ich feststelle, dass dies häufig bei Verwendung von Skype oder Google Hangout mit einem Headset der Fall ist. Um zu beheben, dass manchmal ein Neustart von X hilft, ist manchmal ein vollständiges Herunterfahren / Neustarten erforderlich. setxkbmap / xdotool scheint nicht zurückgesetzt zu werden.

Server: macOS High Sierra 10.13.6
Client: Linux Mint 18.3
Netzwerk: LAN-Verbindung zu demselben Switch, demselben Subnetz (kein Wifi)
Barriere 2.3.2-Release-210c2b70

Was in Barrier würde dazu führen, dass Metatasten im Client "gedrückt" werden? Es muss ein Ereignis geben, das eine Zustandsänderung verursacht und dann verhindert, dass es zurückgesetzt wird, nehme ich vielleicht naiv an.

Gleiches Problem mit der Umschalttaste, die nicht vom Client freigegeben wurde. Ich würde den Titel umbenennen, da er mehr Modifikatoren als nur Superschlüssel zu betreffen scheint.

Betriebssysteme
Server: Ubuntu 18.04 (Kernel 4.15.0-99-generic)
Client: Ubuntu 18.04 (Kernel 5.3.0-51-generic)

Barriere-Version
Server: barriere 2.3.2-13-g9080ce45
Client: Barrieren 2.3.2-13-g9080ce45

Ähnliches Problem in Synergy https://github.com/symless/synergy-core/issues/6459 gefunden

Kleines Update, um zu verdeutlichen, dass die unveröffentlichte Taste jedes Mal auftritt, wenn ich die Umschalttaste drücke, sodass es unwahrscheinlich ist, dass sie durch ein Netzwerkproblem verursacht wird.

Server: Barriere 2.3.2-Snapshot-210c2b70 (Windows 10 1909)
Client: Barriere 2.3.2-RELEASE-00000000 (Arch Linux aktuell, Mate 1.24 über Xorg)

Der CTRL-Client bleibt auf dem Client hängen und drückt STRG-ALT-ENTF, während auf dem Client das Menü Server (Windows) (Sperren | SwitchUser | Abmelden | Task-Manager) und dann ESC aufgerufen wird, um zum Desktop zurückzukehren einige Sekunden (höchstens 20 Sekunden), dann bleibt es wieder von alleine hängen.

Protokolle auf Debug2-Ebene auf Client und Server zeigen nichts Nützliches an, nur die Meldungen "Bildschirm betreten / verlassen".

Der Fehler macht den Client ziemlich unbrauchbar, da er einfache Tastenanschläge aufgrund der Strg-Beteiligung als Befehle interpretiert.

Ich erlebe dies auch, da sowohl die Strg- als auch die Alt-Taste auf dem Client stecken bleiben.
Client und Server sind beide Ubuntu, beide Version 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
Die auf dem Client gedrückte Umschalttaste stoppt die Arbeit anderer Tasten, es sei denn, ich habe die Umschalttaste noch gedrückt. zB nach der Eingabe von L kann ich nur andere Großbuchstaben eingeben.
Wenn Sie den Zeiger zurück zum Server und dann zurück zum Client bewegen, wird er zurückgesetzt.

Passiert regelmäßig zwischen meinen beiden Linux Mint (20 und 19) Computern mit Barrier 2.3.3.

Es stellt sich heraus, dass die rechte Umschalttaste mit der Bezeichnung SHIFT_R hängen bleibt.
Ein einfaches Drücken / Loslassen der Taste behebt das Problem.

Feststeckende Schlüssel können folgendermaßen erkannt werden: xev | grep 'keycode .* (.*)'

Zusätzlich zu meinem früheren Kommentar geschieht dies häufig im Zusammenhang mit einer der folgenden Aktivitäten auf dem Linux-Client:

• Schnelle Fensterschalter (z. B. Alt-Tab, in schneller Reihenfolge gedrückt, dh Alt-Tab / Alt-Tab / Alt-Tab im Gegensatz zu Alt-Tab-Tab-Tab). das ist zeitweise
• Verwenden von Audio- oder Video-Chat-Apps wie Zoom, Skype, Hangout. Dies ist in etwa 7/10 Fällen ziemlich vorhersehbar
• über WLAN mit dem Netzwerk verbunden sein (anstelle von Ethernet)
• Umstellung von WLAN-Verbindung auf Ethernet. in 8/10 Fällen ziemlich vorhersehbar.

Sobald die Taste auf Lager ist (für mich ist es die Strg-Taste), treten Sekunden bis Minuten später andere Symptome auf, z. B. die Möglichkeit, keine zufälligen Zeichen in ein neues Terminalfenster einzugeben, keine Großbuchstaben oder überhaupt keine Tastatureingabe. Normalerweise verschlechtert sich die Situation und die einzige Lösung ist ein Neustart.

Beachten Sie, dass dies manchmal auch ohne diese Aktivitäten geschieht, jedoch seltener.

Klient:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Fr 12 Jun 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrier 2.3.2-snapshot-210cb270
Erstellungsdatum: Freitag, 5. Juni 2020

Server:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: Mi 27. Mai 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barriere: 2.3.2-Release-210cb270
Erstellungsdatum: 3. Oktober 2019

Netzwerk: Ethernet, 1 GB, dasselbe Subnetz, manchmal WLAN (Barriere und Client befinden sich auf demselben Router, der Server ist jedoch über Ethernet verbunden, der Client über WLAN).

Aktualisiert

26. August 2020 - WLAN-Verbindung als Beitrag zur Frequenz hinzugefügt
28. August 2020 - WLAN wurde zum Ethernet-Switch hinzugefügt, um zur Frequenz beizutragen

Wenn ich heute auf dieses Problem stoße, denke ich, dass ich es ziemlich regelmäßig reproduzieren kann. Der Versuch, genaue Schritte einzugrenzen.

Was ich bisher habe, ist Folgendes:

1. Weisen Sie eine Verknüpfung zu, um die Barriere auf dem Client zu starten (ich habe STRG-ALT-UMSCHALT-F9 verwendet).
2. Starten Sie die Barriere mithilfe der Verknüpfung mit der direkt mit dem Client verbundenen sekundären Tastatur (beachten Sie, dass sie zuvor nicht ausgeführt wurde).
3. Wechseln Sie mit der primären Tastatur, die mit dem Server verbunden ist, zum Client (mithilfe der Barriereverknüpfung STRG-ALT-UMSCHALT-F12).
4. Drücken Sie eine beliebige Modifizierertaste auf der Servertastatur (eigentlich nicht erforderlich, bewirkt jedoch eine Aktualisierung von xkbwatch).

Ich stellte fest, dass zumindest zu einem bestimmten Zeitpunkt mehrere Barriereprozesse auf dem Linux-Client ausgeführt wurden (nicht Barriere, sondern Barriere). Ich werde alles neu starten und sehen, ob ich eine Reihe von Schritten eingrenzen kann, die das Problem sauber reproduzieren.

OK, ich habe das noch ein bisschen getestetreproduziert zuverlässig das Problem:

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)

Wenn Sie dies sorgfältig durchlesen, werden Sie feststellen, dass ich mich einmal erholen konnte, aber ein zweites Mal konnte es sich nicht erholen.

Das Seltsame ist, dass es die ALT-Taste ist, die sie auszulösen scheint, obwohl bei diesem Versuch die STRG- und UMSCHALTTASTE stecken geblieben sind. Ich habe auch festgestellt, dass die Verwendung von xdotool zum Zurücksetzen von Modifikatoren funktioniert, aber ich hatte Probleme, ALT zum Löschen zu bringen, bis ich die folgende Befehlszeile verwendet habe, die von @joshskidmore oben kopiert wurde und die Aufgabe zu

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

Vielen Dank, dass Sie @joshskidmore!

Beachten Sie auch, dass diesmal auf dem Linux-Client nie ein doppelter Barriereprozess festgestellt wurde.

Ein weiterer Datenpunkt: Mit SSH zum Anmelden am Linux-Computer und zum Starten der Barriere tritt das Problem nicht auf.

Hmm, und ein weiterer Datenpunkt: Wenn Sie sich mit SSH beim Linux-Computer anmelden und die Barriere starten, während Sie STRG-ALT-UMSCHALT auf der sekundären USB-Tastatur (direkt mit dem Linux-Computer verbunden) gedrückt halten, wird das Problem reproduziert.

Ich kann das Problem jetzt zuverlässig reproduzieren:

1. Linux-Client (Laptop), MacOS-Server - Client ist erfolgreich mit Server (LAN-Netzwerk) verbunden. funktioniert ohne Probleme für eine beliebige Zeitspanne
2. Hot-Unplug-Laptop für unterwegs. Schalten Sie irgendwann WLAN ein und arbeiten Sie direkt an der eingebauten Tastatur und Maus (dh es ist keine Verbindung zum Barrier-Server möglich, anderes Netzwerk).
3. Stecken Sie den Stecker wieder in die Dockingstation, das WLAN ist noch eingeschaltet, die Barriere verbindet sich wieder mit dem Server
4. Mit ein paar Tastenanschlägen und Mausklicks beginnen seltsame Dinge zu passieren. Strg-Taste steckt fest. Durch Eingabe von Fenstern werden Fenster nach Belieben geschlossen oder geöffnet (wahrscheinlich eine Kombination aus Strg + Taste). Selbst Mausklicks erreichen nicht die erwartete Leistung (z. B. unmöglich, ein Fenster zu schließen oder einen neuen Tab in Chrome zu öffnen).

Nur ein Neustart löst das Problem.

Hinweis: Dies ist nicht der Fall, wenn die Barriere nicht ausgeführt wird. Ich komme zu dem Schluss, dass es sich nicht um ein Linux / Hardware-Problem handelt.

Klient:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Fr 12 Jun 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrier 2.3.2-snapshot-210cb270
Erstellungsdatum: Freitag, 5. Juni 2020

Server:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: Mi 27. Mai 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barriere: 2.3.2-Release-210cb270
Erstellungsdatum: 3. Oktober 2019

Als es mir passierte, steckte ich nichts ein oder aus. Beide Laptops blieben durchgehend über WLAN (es sei denn, es gab einige stille Unterbrechungen und Wiederverbindungen, die mir nicht bekannt sind - aber ich habe keinen Grund, stille Unterbrechungen zu vermuten.

Ich habe das gleiche Problem wie Sie, das die Barriere unbrauchbar macht ...: '(