Barrier: superchave (tecla do Windows) fica presa em "pressionada" no cliente

Eu também tenho esse problema com o servidor linux -> cliente linux (ambos Arch). Muitas vezes é uma chave super / meta presa, mas ocasionalmente outros modificadores (shift ou ctrl). Se eu tiver o problema (digamos, sua mudança para este exemplo), se eu reiniciar o servidor de barreira, voltar para a máquina cliente, as coisas estão normais. Se eu voltar imediatamente para o host e, em seguida, de volta para o cliente, a tecla shift fica presa novamente. O modificador também permanece "preso" no teclado físico da máquina cliente. A maneira típica de resolver isso é simplesmente reiniciar a máquina cliente.

Qualquer conselho sobre como eu poderia ajudar a depurar isso seria bem-vindo, pois está me deixando totalmente louco. Consigo usar o SSH na máquina cliente. Eu tentei DISPLAY=:0 xset -q e DISPLAY=:0 xev para depurar e tudo parece normal (nenhum modificador suspenso sendo mostrado com xset e as teclas "corretas" estão sendo pressionadas (por meio de barrierc ou diretamente) no cliente.

Este problema existe usando Barrier 2.2.0, bem como Synergy 1.10.1.

Estou recebendo isso praticamente diariamente também. Estou executando o Arch Linux (atualizado recentemente) no cliente e no servidor. O problema parece afetar principalmente o cliente e, como Josh, continua mesmo depois de eliminar a barreira na máquina cliente.

Para resolver o problema, preciso fazer logout (no meu TTY), fazer login novamente e reiniciar o X.

Acho que isso também é um problema para clientes Windows e que várias teclas modificadoras diferentes podem travar. Se alguém puder reproduzi-lo de forma confiável, isso seria útil.

Para mim, tende a ser a tecla Alt. Eu tenho meu ambiente configurado para que Alt seja usado para mover e redimensionar janelas (Alt + arrastar). É possível que esteja sendo acionado quando eu arrasto uma janela com a tecla Alt para a borda da tela (a borda que normalmente permitiria que meu mouse se movesse de volta para o computador host). Vou ficar de olho quando estiver movendo as janelas e ver se isso tem algo a ver com isso (modificador sendo mantido quando o mouse se move entre os dispositivos).

Eu tenho uma meta-chave presa usando o servidor ubuntu e o cliente Windows. No início, a meta-chave só funciona para o Ubuntu e não funciona para nenhum dos dois.

Existe alguma depuração que possamos fazer ou logs que possamos fornecer que possam ajudar a corrigir esse problema? Neste ponto, estou pensando em mudar para outra coisa, porque ter que fechar toda a minha sessão X-window apenas para fazer meu teclado funcionar diariamente não é sustentável e o problema parece estar piorando.

Se houver algo que eu possa fornecer, esse problema agora ocorre de forma confiável uma vez por dia, então eu poderia fornecer dados muito rápida e repetidamente.

@DarwinSurvivor - A única coisa que encontrei para "zerar" isso (sem sair de X) é o seguinte ... e não é ideal (de forma alguma):

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

Agora tive esse efeito de não modificadores de alguma forma.

Por exemplo, eu uso cVim, então "x" é equivalente a "Ctrl + F4" e fecha a guia atual. Eu tive a tecla x travada, o que significa que quando eu mudo para uma janela cromada, o arquivador rápido fecha todas as minhas guias até que a janela inteira desapareça.

Minha superchave fica presa assim às vezes. Outras chaves como x também podem travar, como o DarwinSurvivor mencionou, embora essas chaves sempre se ajustem sozinhas após um ou dois segundos na minha máquina. Presumi que isso fosse causado por (wi-fi) lag, já que meu cursor também congela enquanto o cliente mascara 'xxxxxxxxx' e para. O problema da superchave parece ser quase permanente, porém, fora de reiniciar o X / reiniciar.

Servidor: Windows 10
Cliente: Linux Mint 19.1 Cinnamon

Eu obtenho o mesmo com a tecla ALT.

O comportamento se torna inverso. Quando pressiono a tecla Alt no host, o cliente se comporta como se não estivesse pressionado. Já aconteceu duas vezes. Não tenho certeza do que consertou da primeira vez.

Servidor: Windows 10
Cliente: macOS High Sierra 10.13.6

*atualizar:
Quando a tecla ALT travar, posso pressionar a tecla CONTROL para resolver o problema.

Eu experimento o mesmo (tecla Super travada, às vezes a tecla Ctrl) com um host MacOS e cliente Linux Mint.

Isso acontece de forma intermitente sem causa conhecida, embora observe que muitas vezes acontece ao usar o Skype ou Google Hangout com um fone de ouvido. Para resolver algumas vezes, reiniciar o X ajuda, às vezes um desligamento / reinicialização total é necessário. setxkbmap / xdotool não parece reiniciar.

Servidor: macOS High Sierra 10.13.6
Cliente: Linux Mint 18.3
Rede: conexão LAN com o mesmo switch, mesma sub-rede (sem Wifi)
Barreira 2.3.2-Release-210c2b70

O que em Barrier faria com que as meta keys sejam "pressionadas" no cliente? Deve haver algum evento que causa uma mudança de estado e impede que seja reiniciado, presumo talvez ingenuamente.

O mesmo problema com a tecla Shift não liberada do cliente. Eu mudaria o nome do título porque parece afetar mais modificadores do que apenas superchave

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

Versão Barreira
Servidor: barrierc 2.3.2-13-g9080ce45
Cliente: barreiras 2.3.2-13-g9080ce45

Encontrado um problema semelhante no Synergy https://github.com/symless/synergy-core/issues/6459

Pequena atualização para deixar claro, a chave não lançada acontece toda vez que pressiono a tecla shift, portanto, é improvável que seja causada por um problema de rede.

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

Da mesma forma, o cliente CTRL travou no cliente, pressionando CTRL-ALT-DEL enquanto o cliente invoca o menu do servidor (Windows) (Bloquear | Trocar usuário | Sair | Gerenciador de tarefas) e, em seguida, ESC para voltar ao desktop desativa o CTRL no cliente por um alguns segundos (20 segundos no máximo), então ele fica preso novamente por conta própria.

Os registros no nível Debug2 no cliente e no servidor não mostram nada de útil, apenas as mensagens de "entrada / saída da tela".

Bug torna o cliente bastante inutilizável, pois interpreta pressionamentos de tecla simples como comandos devido ao envolvimento de ctrl.

Estou experimentando isso também, com as teclas ctrl e alt no cliente travando.
Cliente e servidor são Ubuntu, ambos na versão 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
A tecla Shift pressionada no cliente interrompe o funcionamento de outras teclas, a menos que eu ainda tenha a tecla Shift pressionada. por exemplo, depois de digitar L, só consigo digitar outras letras maiúsculas.
Mover o ponteiro de volta para o servidor e de volta para o cliente o redefine.

Acontece regularmente entre meus dois computadores Linux Mint (20 e 19) com Barrier 2.3.3.

Acontece que a tecla shift direita emperra, rotulada SHIFT_R.
Um simples pressionar / soltar a tecla resolve o problema.

As chaves travadas podem ser detectadas desta forma: xev | grep 'keycode .* (.*)'

Além do meu comentário anterior, isso acontece frequentemente em conexão com qualquer uma das seguintes atividades, no cliente Linux:

• troca rápida de janelas (por exemplo, alt-tab, pressionado em sequência rápida, ou seja, alt-tab / alt-tab / alt tab em oposição a alt-tab-tab-tab). isso é intermitente
• usando aplicativos de áudio ou vídeo de bate-papo como Zoom, Skype, Hangout. isso é bastante previsível em, digamos, 7/10 casos
• estar conectado à rede por wi-fi (em vez de ethernet)
• mudar de conexão wi-fi para ethernet. bastante previsível em 8/10 casos.

Uma vez que a tecla foi armazenada (para mim, é a tecla Ctrl), outros sintomas começam a aparecer segundos a minutos depois, como não ser capaz de digitar caracteres aleatórios em uma nova janela de terminal, sem maiúsculas ou nenhuma entrada de teclado. Normalmente, a situação piora e a única solução é reiniciar.

Observe que às vezes também acontece sem nenhuma dessas atividades, mas mais raramente.

Cliente:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Sex. 12 de junho 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barreira 2.3.2-snapshot-210cb270
Data de construção: sexta-feira, 5 de junho de 2020

Servidor:
Darwin 17.7.0 Darwin Kernel Versão 17.7.0: Quarta, 27 de maio 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barreira: 2.3.2-Release-210cb270
Data de compilação: 3 de outubro de 2019

Rede: Ethernet, 1 GB, mesma sub-rede, às vezes wi-fi (a barreira e o cliente estão no mesmo roteador, porém o servidor está conectado via Ethernet, o cliente via wi-fi)

Atualizada

26 de agosto de 2020 - adicionada conexão wi-fi como um contribuinte para a frequência
28 de agosto de 2020 - adicionado wi-fi ao switch Ethernet como um contribuidor para a frequência

Encontrando esse problema hoje, acho que posso reproduzi-lo com bastante regularidade. Tentando restringir etapas exatas.

O que eu tenho até agora é:

1. Atribua um atalho para iniciar a barreira no cliente (usei CTRL-ALT-SHIFT-F9)
2. Comece a barreira usando o atalho com o teclado secundário conectado diretamente ao cliente (observe que não estava em execução antes)
3. Alterne a tela para o cliente com teclado principal conectado ao servidor (usando um atalho de barreira, CTRL-ALT-SHIFT-F12)
4. Pressione qualquer tecla modificadora no teclado do servidor (na verdade não é necessário, mas faz com que o xkbwatch seja atualizado)

Descobri que, pelo menos em um ponto, havia vários processos de barreira em execução (não barrierc, mas barreira), no cliente Linux. Vou reiniciar tudo do zero e ver se consigo restringir um conjunto de etapas que reproduzem o problema de forma limpa.

OK, eu fiz mais alguns testes quereproduz o problema de forma confiável:

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)

Se você ler com atenção, descobrirá que uma vez consegui me recuperar, mas, na segunda vez, não consegui recuperar.

O curioso é que é a tecla ALT que parece acioná-lo, embora, nessa tentativa, as teclas CTRL e SHIFT tenham sido as que travaram. Eu também descobri que usar xdotool para redefinir modificadores funciona, mas tive problemas para limpar ALT até usar a seguinte linha de comando, copiada de @joshskidmore acima, que parece fazer o trabalho (observe que preciso faça login via SSH para executá-lo, já que os modificadores travados tornam impossível executar comandos diretamente na máquina do 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

Obrigado @joshskidmore!

Observe também que, desta vez, nunca houve um processo de barreira duplicado detectado no cliente Linux.

Outro dado: usando SSH para fazer login na máquina linux e iniciar a barreira, o problema não acontece.

Hmm, e outro ponto de dados: usando SSH para fazer o login na máquina linux e iniciar a barreira, ENQUANTO pressiona CTRL-ALT-SHIFT no teclado USB secundário (conectado diretamente à máquina linux), reproduz o problema.

Agora posso reproduzir o problema de forma confiável:

1. cliente linux (laptop), servidor macos - o cliente foi conectado com sucesso ao servidor (rede LAN). funciona sem problemas por qualquer período de tempo
2. laptop hot-unplug, em movimento. em algum momento, ligue o wi-fi e trabalhe diretamente no teclado e mouse integrados (ou seja, nenhuma conexão com o servidor de barreira é possível, rede diferente)
3. conecte de volta à docking station novamente, wi-fi ainda ligado, barreira conecta de volta ao servidor perfeitamente
4. algumas teclas e cliques do mouse, coisas estranhas começam a acontecer. A tecla ctrl está presa. digitar fecha ou abre janelas à vontade (provavelmente alguma combinação de teclas ctrl +), até mesmo cliques do mouse não conseguem realizar o esperado (por exemplo, impossível fechar uma janela ou abrir uma nova guia no Chrome).

Apenas a reinicialização resolve o problema.

Nota: isso não acontece quando a barreira não está funcionando. Concluo que não é um problema de Linux / hardware.

Cliente:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Sex. 12 de junho 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Barreira 2.3.2-snapshot-210cb270
Data de construção: sexta-feira, 5 de junho de 2020

Servidor:
Darwin 17.7.0 Darwin Kernel Versão 17.7.0: Quarta, 27 de maio 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Barreira: 2.3.2-Release-210cb270
Data de compilação: 3 de outubro de 2019

Quando aconteceu comigo, eu não estava conectando ou desconectando nada. Ambos os laptops permaneceram em WiFi durante todo o tempo (a menos que tenha havido algumas desconexões e reconexões silenciosas das quais não estou ciente - mas não tenho razão para suspeitar de quaisquer desconexões silenciosas.

Eu tenho o mesmo problema que você que torna a barreira inutilizável ...: '(