Os atalhos de teclado param de funcionar de forma intermitente

2

editar: Como pode ser visto a partir da resposta, isso realmente não tem nada a ver com a espera ou hibernação, mas sim que se correlacionou comigo, muitas vezes fechando a janela do aplicativo (que provocou o bug) antes de entrar em espera do tempo.

Eu tenho visto várias pessoas relatando isso em vários lugares da rede, sem qualquer solução, mas pensei em adicionar a minha em qualquer caso:

Muitas vezes, depois de voltar ao computador depois de algum tempo (quando entrou em espera), noto que alguns atalhos pararam de funcionar. Isso faz não só acontecer no terminal, mas também no Chrome (Ctrl-L, Ctrl-R, F5, todas as paradas funcionam). Também não afeta todos os atalhos de ctrl: Ctrl-C ainda está funcionando por exemplo (graças a Deus!).

Existe alguma maneira de depurar isso? Tentar o xev anterior não me levou a nenhum lugar, mas talvez haja alguma maneira de descobrir o que está impedindo que meus toques de teclado cheguem aos programas?

edit: Eu posso ver algo estranho acontecendo com o Ctrl-R

Algo está pegando o atalho de teclado!

Saída capturada de xev

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24547557, (-130,529), root:(0,633),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 37, synthetic NO, window 0x5200001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x5200001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  4294967278 0   0   0   0   0   0   0   0   0   0   0   0   2   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24548550, (-130,529), root:(0,633),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Compare isso com Ctrl-C

podemos ver facilmente quatro eventos lógicos acontecendo aqui

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724066, (572,852), root:(702,956),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724818, (572,852), root:(702,956),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XmbLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724966, (572,852), root:(702,956),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24725339, (572,852), root:(702,956),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
    
por oligofren 15.06.2017 / 15:25

1 resposta

3

Consegui encontrar o mais improvável culpado: o aplicativo Caprine Messenger ! Isso também pode acontecer com muitas outras aplicações feitas com a estrutura Electron (Spotify, Atom, VS Code) até o bug na biblioteca de atalhos é corrigido.

Agora sei como reproduzir consistentemente o bug depois de ler o relatório de erros no rastreador de problemas de elétrons : feche o aplicativo para que ele apenas fique na bandeja do sistema. Mas antes de chegar lá, consegui encontrar evidências conclusivas de que era Caprine que estava capturando o atalho e que matá-lo resolveu a questão. Foi assim que descobri (pode ser usado para situações semelhantes):

Uma resposta opaca a uma pergunta duplicada explicou que era possível detectar qual aplicativo estava pegando as chaves emitindo algumas teclas mágicas. No começo eu não entendi direito como configurar tudo, pensando que eu tinha que passar por todos os tipos de arcos (mexendo com a configuração do Xorg, desabilitando o vty switching, ++) para configurar uma configuração especial de keymapping, até que me dei conta de que a resposta, na verdade, também descreveu como acionar essas combinações de teclas programaticamente!

Então tudo que eu precisava fazer era abrir duas janelas de terminal. Na primeira janela do terminal eu comecei a registrar eventos no sistema Xorg:

tail -f /var/log/Xorg.0.log > out.txt

Na outra janela eu ativei eventos que emitiram as combinações de teclas para o sistema Xorg:

KEY="ctrl+r"                  # the combination that was "grabbed"
xdotool keydown ${KEY};       # start pressing the key combo
xdotool key XF86LogGrabInfo;  # the keysym that when emitted asks X to print info on the grabber of the current keys
xdotool keyup ${KEY}          # stop pressing the key combo

Fazer isso programaticamente assim foi muito mais fácil do que fazê-lo manualmente, como um polvo de dedo :-) No evento log capturado na outra janela (13'000 linhas!) os bits interessantes foram aparentes nas primeiras linhas:

[ 24264.517]     detail 71 (mask 0), modifiersDetail 128 (mask 0)
[ 24264.517]     device 'Virtual core keyboard' (3), modifierDevice 'Virtual core keyboard' (3)
[ 24264.517]     core event mask 0x3
[ 24264.517]     owner-events false, kb 1 ptr 1, confine 0x0, cursor 0x0
[ 24264.517]   Printing all registered grabs of client pid 5643 /opt/Caprine/caprine --type=gpu-process --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,59,71 --gpu-vendor-id=0x8086 --gpu-device-id=0x5916 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --service-request-channel-token=B68A5099B5760C39675F51019B3D4F7A --v8-natives-passed-by-fd --v8-snapshot-passed-by-f 
[ 24264.517]   Printing all registered grabs of client pid 5643 /opt/Caprine/caprine --type=gpu-process --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,59,71 --gpu-vendor-id=0x8086 --gpu-device-id=0x5916 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --service-request-channel-token=B68A5099B5760C39675F51019B3D4F7A --v8-natives-passed-by-fd --v8-snapshot-passed-by-f 
[ 24264.517]   Printing all registered grabs of client pid 5684 /usr/lib/slack/slack --disable-gp 
[ 24264.517]   Printing all registered grabs of client pid 5684 /usr/lib/slack/slack --disable-gp 
[ 24264.517]   Printing all registered grabs of client pid 18336 xdotool key XF86LogGrabInfo
[ 24264.517] End list of registered passive grabs
[ 24308.177] (II) Printing all currently active device grabs:
[ 24308.177] Active grab 0x44800160 (core) on device 'Virtual core keyboard' (3):
[ 24308.177]       client pid 5614 /opt/Caprine/caprine 
[ 24308.177]       at 24308139 (from passive grab) (device thawed, state 1)
[ 24308.177]         core event mask 0x3
[ 24308.177]       passive grab type 2, detail 0x1b, activating key 27
[ 24308.177]       owner-events false, kb 1 ptr 1, confine 0, cursor 0x0
[ 24308.177] (II) End list of active device grabs

Depois de matar o Caprine, eu poderia finalmente começar a usar o Ctrl-R no terminal novamente para fazer pesquisas de histórico reverso, assim como atualizar o Chrome! xev também apresenta algo bem diferente do que eu detalhei na questão, agora sendo muito semelhante à saída de Ctrl-L:

KeyPress event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25356738, (917,877), root:(1047,981),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357181, (917,877), root:(1047,981),
    state 0x14, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (12) ""
    XmbLookupString gives 1 bytes: (12) ""
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357315, (917,877), root:(1047,981),
    state 0x14, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (12) ""
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357710, (917,877), root:(1047,981),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

edit: o bug é conhecido

O problema do bug também mostra como consistentemente reproduzir isso (minimizar). Foi causada por um erro na biblioteca electron-localshortcut .

Feito um pequeno util para enviar facilmente esses atalhos programaticamente.

    
por oligofren 16.06.2017 / 19:05