Barrier: la super clé (touche Windows) reste bloquée "enfoncée" sur le client

J'ai aussi ce problème avec le serveur linux -> client linux (les deux Arch). C'est souvent une touche super / méta bloquée, mais parfois d'autres modificateurs (shift ou ctrl). Si je rencontre le problème (disons son décalage pour cet exemple), si je redémarre le serveur de barrière, reviens à la machine cliente, les choses sont normales. Si je reviens immédiatement à l'hôte, puis au client, la touche Maj est à nouveau bloquée. Le modificateur reste également "bloqué" sur le clavier physique de la machine cliente. La manière typique de résoudre ce problème est pour moi de simplement redémarrer l'ordinateur client.

Tout conseil sur la façon dont je pourrais aider à déboguer cela serait apprécié car cela me rend complètement fou. Je suis capable de SSH dans la machine cliente. J'ai essayé DISPLAY=:0 xset -q et DISPLAY=:0 xev pour déboguer et tout semble normal (aucun modificateur maintenu n'est affiché avec xset et les touches «correctes» sont enfoncées (via barrierc ou directement) sur le client.

Ce problème existe en utilisant Barrier 2.2.0 ainsi que Synergy 1.10.1.

J'obtiens cela pratiquement tous les jours aussi. J'utilise Arch Linux (récemment mis à jour) sur le client et le serveur. Le problème semble principalement affecter le client, et comme Josh, continue même après avoir tué la barrière sur la machine cliente.

Pour résoudre le problème, je dois me déconnecter (à mon TTY), me reconnecter et redémarrer X.

Je pense que c'est également un problème pour les clients Windows et que plusieurs touches de modification différentes peuvent rester bloquées. Si quelqu'un peut le reproduire de manière fiable, ce serait utile.

Pour moi, cela a tendance à être la touche Alt. J'ai configuré mon environnement pour que Alt soit utilisé pour déplacer et redimensionner les fenêtres (Alt + glisser). Il est possible que cela se déclenche lorsque je fais glisser une fenêtre vers le bord de l'écran (le bord qui permettrait normalement à ma souris de revenir sur l'ordinateur hôte). Je vais garder un œil sur lorsque je déplace des fenêtres et voir si cela a quelque chose à voir avec cela (le modificateur est maintenu lorsque la souris se déplace entre les périphériques).

J'ai une clé méta bloquée en utilisant le serveur ubuntu et le client Windows. Au début, la clé méta ne fonctionne que pour ubuntu et ensuite ne fonctionne pas pour l'un ou l'autre.

Y a-t-il un débogage que nous pouvons faire ou des journaux que nous pouvons fournir qui pourraient aider à résoudre ce problème? À ce stade, j'envisage de passer à autre chose, car devoir fermer toute ma session X-window juste pour que mon clavier fonctionne quotidiennement n'est pas durable et le problème semble s'aggraver.

S'il y a quelque chose que je peux fournir, ce problème se produit maintenant de manière fiable une fois par jour, donc je pourrais fournir des données très rapidement et à plusieurs reprises.

@DarwinSurvivor - La seule chose que j'ai trouvée pour "réinitialiser" ceci (sans quitter X) est la suivante ... et ce n'est pas idéal (du tout):

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

J'ai maintenant eu cet effet non-modificateurs d'une manière ou d'une autre.

Par exemple, j'utilise cVim, donc "x" équivaut à "Ctrl + F4" et ferme l'onglet actuel. J'ai eu la touche x bloquée, ce qui signifie que lorsque je passe à une fenêtre chromée, Fast-Filer ferme tous mes onglets jusqu'à ce que toute la fenêtre disparaisse.

Ma super-clé reste bloquée comme ça parfois. D'autres touches comme x peuvent également rester bloquées, comme DarwinSurvivor l'a mentionné, bien que ces touches se corrigent toujours après une seconde ou deux sur ma machine. J'ai supposé que cela était causé par un décalage (wi-fi) car mon curseur se fige également tandis que le client écrase 'xxxxxxxxx' puis s'arrête. Le problème super-clé semble cependant être presque permanent, en dehors du redémarrage de X / du redémarrage.

Serveur: Windows 10
Client: Linux Mint 19.1 Cinnamon

J'obtiens la même chose avec la touche ALT.

Le comportement devient inverse. Lorsque j'appuie sur la touche Alt de l'hôte, le client se comporte comme s'il n'était pas enfoncé. Cela s'est déjà produit deux fois. Je ne sais pas ce qui l'a corrigé la première fois.

Serveur: Windows 10
Client: macOS High Sierra 10.13.6

*mettre à jour:
Lorsque la touche ALT est bloquée, je peux appuyer sur la touche CONTROL pour le résoudre.

Je ressens la même chose (Super clé bloquée, parfois la touche Ctrl) avec un hôte MacOS et un client Linux Mint.

Cela se produit par intermittence sans cause connue, bien que j'observe que cela se produit souvent lorsque vous utilisez Skype ou Google Hangout avec un casque. Pour résoudre parfois le redémarrage de X aide, parfois un arrêt / redémarrage complet est nécessaire. setxkbmap / xdotool ne semble pas se réinitialiser.

Serveur: macOS High Sierra 10.13.6
Client: Linux Mint 18.3
Réseau: connexion LAN au même commutateur, même sous-réseau (pas de Wifi)
Barrière 2.3.2-Release-210c2b70

Dans Barrier, qu'est-ce qui ferait «enfoncer» les touches méta dans le client? Il doit y avoir un événement qui provoque un changement d'état et l'empêche ensuite de se réinitialiser, je suppose peut-être naïvement.

Même problème avec la touche Shift non libérée du client. Je renommerais le titre car il semble affecter plus de modificateurs qu'une simple super clé.

Systèmes d'exploitation
Serveur: Ubuntu 18.04 (Kernel 4.15.0-99-generic)
Client: Ubuntu 18.04 (noyau 5.3.0-51-générique)

Version barrière
Serveur: barrierc 2.3.2-13-g9080ce45
Client: barrières 2.3.2-13-g9080ce45

Problème similaire trouvé dans Synergy https://github.com/symless/synergy-core/issues/6459

Petite mise à jour pour que ce soit clair, la clé non libérée se produit chaque fois que j'appuie sur la touche Maj, il est donc peu probable qu'elle soit causée par un problème de réseau.

Serveur: barrière 2.3.2-snapshot-210c2b70 (Windows 10 1909)
Client: barrière 2.3.2-RELEASE-00000000 (Arch Linux à jour, Mate 1.24 sur Xorg)

Idem, le client CTRL est bloqué sur le client, en appuyant sur CTRL-ALT-DEL alors que le client appelle le menu Serveur (Windows) (Verrouiller | SwitchUser | Déconnexion | Gestionnaire des tâches), puis ESC pour revenir au bureau dé-bloque CTRL sur le client pour un quelques secondes (20 secondes au maximum), puis il se bloque à nouveau tout seul.

Les journaux au niveau Debug2 à la fois sur le client et sur le serveur ne montrent rien d'utile, juste les messages "entrée / sortie d'écran".

Le bogue rend le client assez inutilisable, car il interprète les frappes simples comme des commandes en raison de l'implication de ctrl.

Je rencontre également cela, avec les touches Ctrl et Alt sur le client bloquées.
Le client et le serveur sont tous deux Ubuntu, tous deux version 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
La touche Maj enfoncée sur le client arrête le fonctionnement des autres touches à moins que la touche Maj soit toujours enfoncée. par exemple, après avoir tapé L, je ne peux taper que d'autres lettres majuscules.
Le déplacement du pointeur vers le serveur puis vers le client le réinitialise.

Cela arrive régulièrement entre mes deux ordinateurs Linux Mint (20 et 19) avec Barrier 2.3.3.

Il s'avère que la touche Maj droite reste bloquée, étiquetée SHIFT_R.
Une simple pression / relâchement de la touche résout le problème.

Les clés bloquées peuvent être détectées de cette façon: xev | grep 'keycode .* (.*)'

En plus de mon commentaire précédent, cela se produit fréquemment en relation avec l'une des activités suivantes, sur le client Linux:

• commutateurs de fenêtre rapides (par exemple alt-tab, pressés en séquence rapide, c'est-à-dire alt-tab / alt-tab / alt tab par opposition à alt-tab-tab-tab). c'est intermittent
• en utilisant des applications de chat audio ou vidéo comme Zoom, Skype, Hangout. c'est tout à fait prévisible dans, disons 7/10 cas
• être connecté au réseau via wifi (au lieu d'Ethernet)
• passer de la connexion wifi à Ethernet. tout à fait prévisible dans 8/10 cas.

Une fois que la clé est en stock (pour moi, c'est la touche Ctrl), d'autres symptômes commencent à apparaître quelques secondes à quelques minutes plus tard, comme l'impossibilité de taper des caractères aléatoires dans une nouvelle fenêtre de terminal, pas de majuscules ou pas de saisie au clavier du tout. Généralement, la situation empire et la seule solution est de redémarrer.

Notez que cela arrive aussi parfois sans aucune de ces activités, mais plus rarement.

Client:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP ven 12 juin 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrière 2.3.2-snapshot-210cb270
Date de construction: vendredi 5 juin 2020

Serveur:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: mercredi 27 mai 17:00:02 PDT 2020; racine: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barrière: 2.3.2-Release-210cb270
Date de construction: 3 octobre 2019

Réseau: Ethernet, 1 Go, même sous-réseau, parfois wifi (barrière et client sont sur le même routeur, cependant le serveur est connecté via Ethernet, client via wifi)

Mis à jour

26 août 2020 - Ajout d'une connexion wifi en tant que contributeur à la fréquence
28 août 2020 - Ajout du wifi au commutateur Ethernet en tant que contributeur à la fréquence

Rencontrant ce problème aujourd'hui, je pense que je peux le reproduire assez régulièrement. Essayer de réduire les étapes exactes.

Ce que j'ai jusqu'à présent, c'est ceci:

1. Attribuer un raccourci pour démarrer la barrière sur le client (j'ai utilisé CTRL-ALT-SHIFT-F9)
2. Démarrer la barrière en utilisant le raccourci avec le clavier secondaire directement connecté au client (notez qu'il ne fonctionnait pas avant cela)
3. Basculer l'écran vers le client avec le clavier principal connecté au serveur (à l'aide d'un raccourci de barrière, CTRL-ALT-SHIFT-F12)
4. Appuyez sur n'importe quelle touche de modification sur le clavier du serveur (en fait pas nécessaire, mais entraîne la mise à jour de xkbwatch)

J'ai trouvé que, au moins à un moment donné, j'avais plusieurs processus de barrière en cours d'exécution (pas de barrière, mais de barrière), sur le client Linux. Je vais tout redémarrer et voir si je peux réduire un ensemble d'étapes qui reproduisent proprement le problème.

OK, j'ai fait quelques tests supplémentairesreproduit de manière fiable le problème:

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)

Si vous lisez attentivement ceci, vous constaterez que j'ai pu récupérer une fois, mais une deuxième fois, cela n'a pas été récupéré.

La chose étrange est que c'est la touche ALT qui semble le déclencher, même si, dans cette tentative, les touches CTRL et SHIFT sont celles qui sont restées bloquées. J'ai également constaté que l'utilisation de xdotool pour réinitialiser les modificateurs fonctionne, mais j'ai eu du mal à faire effacer ALT jusqu'à ce que j'utilise la ligne de commande suivante, copiée de @joshskidmore ci-dessus, qui semble faire le travail (note que je dois connectez-vous via SSH pour l'exécuter car les modificateurs bloqués rendent impossible l'exécution de commandes directement sur la machine ubuntu):

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

Merci @joshskidmore!

Notez également que cette fois, il n'y a jamais eu de processus de barrière en double détecté sur le client Linux.

Un autre point de données: en utilisant SSH pour se connecter à la machine Linux et démarrer la barrière, le problème ne se produit pas.

Hmm, et un autre point de données: utiliser SSH pour se connecter à la machine linux et démarrer la barrière, TOUT EN maintenant CTRL-ALT-SHIFT enfoncé sur le clavier usb secondaire (directement connecté à la machine linux), reproduit le problème.

Je peux maintenant reproduire le problème de manière fiable:

1. client linux (ordinateur portable), serveur macos - le client est connecté avec succès au serveur (réseau LAN). fonctionne sans problème pour n'importe quelle durée
2. ordinateur portable hot-unplug, en déplacement. à un moment donné, activez le wifi et travaillez directement sur le clavier et la souris intégrés (c'est-à-dire qu'aucune connexion au serveur de barrière n'est possible, réseau différent)
3. rebranchez à la station d'accueil, le wifi toujours activé, la barrière se reconnecte au serveur très bien
4. quelques touches et clics de souris dessus, des choses étranges commencent à se produire. La touche Ctrl est bloquée. taper ferme ou ouvre les fenêtres à volonté (probablement une combinaison ctrl + touches), même les clics de souris ne parviennent pas à accomplir ce qui est attendu (par exemple impossible de fermer une fenêtre ou d'ouvrir un nouvel onglet dans Chrome).

Seul le redémarrage résout le problème.

Remarque: cela ne se produit pas lorsque la barrière ne fonctionne pas. Je conclus qu'il ne s'agit pas d'un problème Linux / matériel.

Client:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP ven 12 juin 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrière 2.3.2-snapshot-210cb270
Date de construction: vendredi 5 juin 2020

Serveur:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: mercredi 27 mai 17:00:02 PDT 2020; racine: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barrière: 2.3.2-Release-210cb270
Date de construction: 3 octobre 2019

Quand cela m'est arrivé, je n'ai rien branché ni débranché. Les deux ordinateurs portables sont restés en WiFi tout au long (à moins qu'il y ait eu des déconnexions et des reconnexions silencieuses dont je ne suis pas au courant - mais je n'ai aucune raison de suspecter des déconnexions silencieuses.

J'ai le même problème que vous qui rend la barrière inutilisable ...: '(