Barrier: super tecla (tecla de Windows) se atasca en "presionada" en el cliente

También tengo este problema con el servidor linux -> cliente linux (ambos Arch). A menudo es una tecla super / meta atascada, pero ocasionalmente otros modificadores (shift o ctrl). Si experimento el problema (digamos su turno para este ejemplo), si reinicio el servidor de barrera, vuelvo a la máquina cliente, las cosas son normales. Si vuelvo inmediatamente al host y luego al cliente, la tecla de mayúsculas se bloquea de nuevo. El modificador también permanece "atascado" en el teclado físico de la máquina cliente. La forma típica de resolver esto es reiniciar la máquina cliente.

Cualquier consejo sobre cómo podría ayudar a depurar esto sería apreciado, ya que me está volviendo absolutamente loco. Puedo SSH en la máquina cliente. Probé DISPLAY=:0 xset -q y DISPLAY=:0 xev para depurar y todo parece normal (no se muestran modificadores retenidos con xset y se presionan las teclas "correctas" (a través de la barrera o directamente) en el cliente.

Este problema existe utilizando Barrier 2.2.0 y Synergy 1.10.1.

También recibo esto prácticamente a diario. Estoy ejecutando Arch Linux (actualizado recientemente) tanto en el cliente como en el servidor. El problema parece afectar principalmente al cliente y, como Josh, continúa incluso después de eliminar la barrera en la máquina del cliente.

Para solucionar el problema, tengo que cerrar la sesión (en mi TTY), volver a iniciar sesión y reiniciar X.

Creo que esto también es un problema para los clientes de Windows y que varias teclas modificadoras diferentes pueden bloquearse. Si alguien puede reproducirlo de manera confiable, sería útil.

Para mí, tiende a ser la tecla Alt. Tengo mi entorno configurado para que Alt se use para mover y cambiar el tamaño de las ventanas (Alt + arrastrar). Es posible que se active cuando presiono la tecla Alt y arrastro una ventana hasta el borde de la pantalla (el borde que normalmente permitiría que mi mouse regrese a la computadora host). Estaré atento cuando mueva las ventanas y veré si eso tiene algo que ver con eso (el modificador se mantiene cuando el mouse se mueve entre dispositivos).

Tengo una clave meta atascada usando el servidor ubuntu y el cliente de Windows. Al principio, la clave meta solo funciona para ubuntu y luego no funciona para ninguno.

¿Hay alguna depuración que podamos hacer o registros que podamos proporcionar que puedan ayudar a solucionar este problema? En este punto, estoy contemplando cambiar a otra cosa porque tener que cerrar toda mi sesión de X-window solo para que mi teclado funcione a diario no es sostenible y el problema parece estar empeorando.

Si hay algo que pueda proporcionar, este problema ahora ocurre de manera confiable una vez al día, por lo que podría proporcionar datos de manera muy rápida y repetida.

@DarwinSurvivor - Lo único que encontré para "restablecer" esto (sin dejar X) es lo siguiente ... y no es ideal (en absoluto):

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

Ahora he tenido este efecto de no modificadores de alguna manera.

Por ejemplo, yo uso cVim, por lo que "x" es equivalente a "Ctrl + F4" y cierra la pestaña actual. La tecla x se atascó, lo que significa que cuando cambio a una ventana de Chrome, el archivador rápido cierra todas mis pestañas hasta que desaparece toda la ventana.

Mi superclave se atasca así a veces. Otras teclas como x también pueden atascarse, como lo mencionó DarwinSurvivor, aunque esas teclas siempre se corrigen después de uno o dos segundos en mi máquina. Supuse que fue causado por un retraso (wi-fi) ya que mi cursor también se congela mientras el cliente machaca 'xxxxxxxxx' y luego se detiene. Sin embargo, el problema de la superclave parece ser casi permanente, aparte de reiniciar X / reiniciar.

Servidor: Windows 10
Cliente: Linux Mint 19.1 Cinnamon

Obtengo lo mismo con la tecla ALT.

El comportamiento se vuelve inverso. Cuando presiono la tecla Alt en el host, el cliente se comporta como si no estuviera presionada. Ya pasó dos veces. No estoy seguro de qué lo solucionó la primera vez.

Servidor: Windows 10
Cliente: macOS High Sierra 10.13.6

*actualizar:
Cuando la tecla ALT se atasca, puedo presionar la tecla CONTROL para resolverlo.

Experimento lo mismo (Super tecla bloqueada, a veces la tecla Ctrl) con un host MacOS y un cliente Linux Mint.

Esto sucede de forma intermitente sin una causa conocida, aunque observo que a menudo sucede cuando se usa Skype o Google Hangout con un auricular. Para resolver a veces, reiniciar X ayuda, a veces se necesita un apagado / reinicio completo. setxkbmap / xdotool no parece reiniciarse.

Servidor: macOS High Sierra 10.13.6
Cliente: Linux Mint 18.3
Red: conexión LAN al mismo conmutador, misma subred (sin Wifi)
Barrera 2.3.2-Release-210c2b70

¿Qué causa en Barrier que se "presionen" las teclas meta en el cliente? Debe haber algún evento que cause un cambio de estado y luego evite que se reinicie, supongo que quizás ingenuamente.

El mismo problema con la tecla Shift no liberada del cliente. Cambiaría el nombre del título, ya que parece afectar a más modificadores que solo la superclave.

Sistemas operativos
Servidor: Ubuntu 18.04 (Kernel 4.15.0-99-genérico)
Cliente: Ubuntu 18.04 (Kernel 5.3.0-51-genérico)

Versión de barrera
Servidor: barrerac 2.3.2-13-g9080ce45
Cliente: barreras 2.3.2-13-g9080ce45

Se encontró un problema similar en Synergy https://github.com/symless/synergy-core/issues/6459

Pequeña actualización para que quede claro, la tecla inédita ocurre cada vez que presiono la tecla Mayús, por lo que es poco probable que sea causada por un problema de red.

Servidor: barrera 2.3.2-snapshot-210c2b70 (Windows 10 1909)
Cliente: barrera 2.3.2-RELEASE-00000000 (Arch Linux actualizado, Mate 1.24 sobre Xorg)

Lo mismo, el cliente CTRL se atascó en el cliente, al presionar CTRL-ALT-SUPR mientras está en el cliente, se invoca el menú Servidor (Windows) (Bloquear | Cambiar usuario | Cerrar sesión | Administrador de tareas), luego ESC para volver al escritorio, se destraba CTRL en el cliente para un unos segundos (20 segundos como máximo), luego se atasca nuevamente por sí solo.

Los registros a nivel de Debug2 tanto en el cliente como en el servidor no muestran nada útil, solo los mensajes de "pantalla de entrada / salida".

El error hace que el cliente sea bastante inutilizable, ya que interpreta las pulsaciones de teclas simples como comandos debido a la participación de ctrl.

También estoy experimentando esto, con las teclas ctrl y alt en el cliente atascadas.
El cliente y el servidor son Ubuntu, ambos versión 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
La tecla Mayús presionada en el cliente detiene el funcionamiento de otras teclas a menos que todavía tenga la tecla Mayús presionada. por ejemplo, después de escribir L, solo puedo escribir otras letras mayúsculas.
Mover el puntero al servidor y luego al cliente lo restablece.

Ocurre regularmente entre mis dos computadoras Linux Mint (20 y 19) con Barrier 2.3.3.

Resulta que la tecla de mayúsculas derecha se atasca, etiquetada SHIFT_R.
Una simple pulsación / liberación de la tecla resuelve el problema.

Las claves atascadas se pueden detectar de esta manera: xev | grep 'keycode .* (.*)'

Además de mi comentario anterior, esto sucede con frecuencia en relación con cualquiera de las siguientes actividades, en el cliente Linux:

• Cambios rápidos de ventana (por ejemplo, alt-tab, presionados en secuencia rápida, es decir, alt-tab / alt-tab / alt tab en lugar de alt-tab-tab-tab). esto es intermitente
• usando aplicaciones de chat de audio o video como Zoom, Skype, Hangout. esto es bastante predecible en digamos 7/10 casos
• estar conectado a la red a través de wifi (en lugar de ethernet)
• cambiar de conexión wifi a ethernet. bastante predecible en 8/10 casos.

Una vez que la clave tiene valores (para mí es la tecla Ctrl), otros síntomas comienzan a aparecer segundos o minutos después, como no poder escribir caracteres aleatorios en una nueva ventana de terminal, sin mayúsculas o sin entrada de teclado. Normalmente, la situación empeora y la única solución es reiniciar.

Tenga en cuenta que también sucede a veces sin ninguna de estas actividades, pero con menor frecuencia.

Cliente:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Vie 12 de junio 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrera 2.3.2-instantánea-210cb270
Fecha de construcción: Viernes 5 de junio de 2020

Servidor:
Darwin 17.7.0 Darwin Kernel Versión 17.7.0: miércoles 27 de mayo 17:00:02 PDT 2020; raíz: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barrera: 2.3.2-Release-210cb270
Fecha de construcción: 3 de octubre de 2019

Red: Ethernet, 1 GB, misma subred, a veces wifi (la barrera y el cliente están en el mismo enrutador, sin embargo, el servidor está conectado a través de Ethernet, el cliente a través de wifi)

Actualizado

26 de agosto de 2020: conexión wifi agregada como factor de frecuencia
28 de agosto de 2020: se agregó wifi al conmutador ethernet como contribuyente a la frecuencia

Al encontrarme con este problema hoy, creo que puedo reproducirlo con bastante regularidad. Tratando de reducir los pasos exactos.

Lo que tengo hasta ahora es esto:

1. Asignar un atajo para iniciar la barrera en el cliente (usé CTRL-ALT-SHIFT-F9)
2. Inicie la barrera usando el acceso directo con el teclado secundario conectado directamente al cliente (tenga en cuenta que no se estaba ejecutando antes de esto)
3. Cambiar la pantalla al cliente con el teclado principal conectado al servidor (usando un atajo de barrera, CTRL-ALT-SHIFT-F12)
4. Presione cualquier tecla modificadora en el teclado del servidor (en realidad no es necesario, pero hace que xkbwatch se actualice)

Descubrí que, al menos en un momento, tenía varios procesos de barrera en ejecución (no barrera, sino barrera) en el cliente Linux. Voy a reiniciar todo de nuevo y veré si puedo reducir un conjunto de pasos que reproduzcan el problema de forma limpia.

OK, hice algunas pruebas más quereproduce de forma fiable el problema:

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 lee esto detenidamente, encontrará que pude recuperarme una vez, pero una segunda vez, no se recuperó.

Lo curioso es que es la tecla ALT la que parece activarla, aunque en este intento fueron las teclas CTRL y MAYÚS las que se atascaron. También descubrí que usar xdotool para restablecer modificadores funciona, pero tuve problemas para borrar ALT hasta que usé la siguiente línea de comando, copiada de @joshskidmore anterior, que parece hacer el trabajo (tenga en cuenta que tengo que inicie sesión a través de SSH para ejecutar esto, ya que los modificadores atascados hacen que sea imposible ejecutar comandos directamente en la máquina 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

¡Gracias @joshskidmore!

También tenga en cuenta que esta vez, nunca se detectó un proceso de barrera duplicado en el cliente Linux.

Otro punto de datos: usando SSH para iniciar sesión en la máquina Linux y comenzar la barrera, el problema no ocurre.

Hmm, y otro punto de datos: usar SSH para iniciar sesión en la máquina Linux e iniciar la barrera, MIENTRAS mantiene presionado CTRL-ALT-SHIFT en el teclado USB secundario (conectado directamente a la máquina Linux), SÍ reproduce el problema.

Ahora puedo reproducir el problema de manera confiable:

1. cliente linux (computadora portátil), servidor macos: el cliente está conectado correctamente al servidor (red LAN). funciona sin problemas durante cualquier período de tiempo
2. portátil de desconexión en caliente, en movimiento. en algún momento, encienda el wifi y trabaje directamente en el teclado y el mouse integrados (es decir, no es posible una conexión al servidor de barrera, una red diferente)
3. Vuelva a conectarlo a la estación de acoplamiento, el wifi aún está encendido, la barrera se conecta de nuevo al servidor sin problemas
4. unas pocas pulsaciones de teclas y clics del ratón, empiezan a suceder cosas extrañas. La tecla ctrl está atascada. escribir cierra o abre ventanas a voluntad (probablemente alguna combinación de teclas Ctrl +), incluso los clics del mouse no logran lo esperado (por ejemplo, es imposible cerrar una ventana o abrir una nueva pestaña en Chrome).

Solo reiniciar resuelve el problema.

Nota: esto no sucede cuando la barrera no está funcionando. Concluyo que no es un problema de Linux / hardware.

Cliente:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Vie 12 de junio 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barrera 2.3.2-instantánea-210cb270
Fecha de construcción: Viernes 5 de junio de 2020

Servidor:
Darwin 17.7.0 Darwin Kernel Versión 17.7.0: miércoles 27 de mayo 17:00:02 PDT 2020; raíz: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barrera: 2.3.2-Release-210cb270
Fecha de construcción: 3 de octubre de 2019

Cuando me sucedió, no estaba conectando ni desconectando nada. Ambas computadoras portátiles se mantuvieron en WiFi en todo momento (a menos que hubiera algunas desconexiones y reconexiones silenciosas de las que no tenga conocimiento, pero no tengo ninguna razón para sospechar que haya desconexiones silenciosas).

Tengo el mismo problema que tú que hace que la barrera sea inutilizable ...: '(