X: alt / ctrl / f1 não funciona mais depois de desligar e ligar novamente o monitor com xrandr

4

(Depois de editar novas informações significativas sobre a questão)

Depois de desativar a exibição na linha de comando ( xrandr --output ... --off ) e depois voltar ( xrandr --output ... --auto ), minha área de trabalho X perde a capacidade de alternar para um console de caractere (ou seja, alt / ctrl / f1 não trabalhar mais).

Outros atalhos de controle X (alt / ctrl / backspace) ainda funcionam.

Por quê? Como reativar esse recurso?

Info: é o Linux Mint, mais recente estável. Os problemas acontecem explicitamente depois que eu desliguei o X com uma linha de comando xrandr --output ... --off , e então liguei novamente na manhã seguinte (com um comando xrandr --output ... --auto ).

Eu uso isso, porque preciso desativá-lo completamente antes de ir para casa e as configurações normais (configurações de energia em algum lugar no painel de controle) não são suficientes ou com bugs.

Meu teclado está bem, por exemplo, xev mostra o evento alt / ctrl / f3 release corretamente:

KeyRelease event, serial 37, synthetic NO, window 0x3c00001,
    root 0x2e1, subw 0x0, time 1622285717, (99,77), root:(961,532),
    state 0xc, keycode 69 (keysym 0x1008fe03, XF86Switch_VT_3), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Mas o evento de pressionamento de tecla não é na lista. Assim, xev não pode ver a pressão de alt / ctrl / f3, mas de alguma forma pode ver o seu lançamento.

Saída de depuração:

$ xmodmap -pke|grep -i xf86switch
keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1
keycode  68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2 F2 F2 XF86Switch_VT_2
keycode  69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3 F3 F3 XF86Switch_VT_3
keycode  70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4 F4 F4 XF86Switch_VT_4
keycode  71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5 F5 F5 XF86Switch_VT_5
keycode  72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6 F6 F6 XF86Switch_VT_6
keycode  73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7 F7 F7 XF86Switch_VT_7
keycode  74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8 F8 F8 XF86Switch_VT_8
keycode  75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9 F9 F9 XF86Switch_VT_9
keycode  76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10 F10 F10 XF86Switch_VT_10
keycode  95 = F11 F11 F11 F11 F11 F11 XF86Switch_VT_11 F11 F11 XF86Switch_VT_11
keycode  96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12 F12 F12 XF86Switch_VT_12

O comando xmodmap -pke | grep ' F[0-9]\+' fornece exatamente o mesmo resultado.

Informações adicionais: a capacidade de alternar para o console de caracteres foi perdida no desligamento e não na energia ligada (assim, tive que ssh na estação de trabalho do meu celular para inserir o comando xrandr --output ... --auto ).

Teste de script: testei o script do @GeorgeVasilou, o que emula o teclado acerta injetando o evento X11. O resultado é negativo, a sequência emulada alt / ctrl / f1 aparece apenas como um único H .

    
por peterh 05.12.2016 / 09:16

1 resposta

2

Este é um comentário estendido e não uma resposta.

No meu sistema, no qual Ctrl + Alt + F1 funciona corretamente, recebo um evento KeyPress para controle e alt , mas não para F1 . Embora eu saiba que funciona desde que fui transferido para o tty1.

Esta é a saída completa de xev no meu caso (apenas para comparação):

root@debi64:/home/gv/Desktop/PythonTests# xev -event keyboard
Outer window is 0x4400001, inner window is 0x4400002

KeymapNotify event, serial 18, synthetic NO, window 0x0,
    keys:  4294967192 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyPress event, serial 25, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11550957, (157,186), root:(748,462),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11550960, (157,186), root:(748,462),
    state 0x8, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553775, (157,186), root:(748,462),
    state 0xc, keycode 67 (keysym 0x1008fe01, XF86Switch_VT_1), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553902, (157,186), root:(748,462),
    state 0xc, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553902, (157,186), root:(748,462),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeymapNotify event, serial 28, synthetic NO, window 0x0,
    keys:  4294967169 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ClientMessage event, serial 28, synthetic YES, window 0x4400001,
    message_type 0x11b (WM_PROTOCOLS), format 32, message 0x119 (WM_DELETE_WINDOW)

Eu também criei um pequeno script python que simula a tecla Ctrl + alt + F1 . Quando executo o script, também sou transferido em tty1 sem problemas.

Você pode até mesmo tentar executar esse script em sua máquina para ver se você está ou não em tty1, como uma verificação / verificação dupla de que seu teclado funciona bem:

link

PS: Em vez de script, você também pode tentar executar #chvt 1 e transferi-lo também para tty1.

Após alguma pesquisa, foi reportado por outros usuários que as teclas Ctrl + alt + fn pararam de funcionar devido às atualizações do xserver (obviamente ), que modificou algumas configurações de resolução que se aplicam em tty's.

Por exemplo, nesta postagem , o problema foi resolvido com a aplicação de uma resolução vga específica durante a inicialização. parâmetro do kernel (vga = modo), como vga = 0x0362. Obviamente, uma daquelas atualizações do sistema bagunçou resoluções nesses caras, então talvez este também seja o seu caso (e só Deus sabe o porquê).

PS: Para ver os modos suportados disponíveis para o seu sistema, você precisa executar hwinfo --framebuffer | grep 'Mode' e selecionar um modo dentre os que serão listados.

A propósito, você incluiu alguma parte do xev com F3 em sua pergunta, mas qual é a saída com F1 ?

UPDATE:
Como solução de problemas adicional, vale a pena tentar alguns dos seguintes procedimentos:

  1. Analisando o código-fonte xrandr , parece que a opção --off executa o os seguintes comandos:

    set_name_xid (&config_output->mode, None);
    set_name_xid (&config_output->crtc, None);
    config_output->changes |= changes_mode | changes_crtc;
    

Você poderia tentar reativar o --output especificando as opções --mode e --crtc xrandr ao invés de --auto (caso a xrandr "automation" não esteja funcionando corretamente).

  1. Neste documento do kernel sobre o console , você pode ver quais são os drivers / módulos suportados para operação de consoles virtuais no diretório /sys/class/vtconsole .
    Você pode comparar os valores de todos os arquivos / módulos durante a inicialização e após o desligamento que você tem um comportamento diferente. Talvez algo esteja modificando esses valores no tempo de desativação.

Esta é uma impressão do meu sistema em que a mudança para tty1-2-3-4-5-6 funciona ok:

root@debi64:/home/gv/Desktop/PythonTests# for f in $(find /sys/class/vtconsole/vtcon0/ -type f);do echo -e "File : $f \c\c\c";echo -e "-VALUE : \c";cat $f;done
File : /sys/class/vtconsole/vtcon0/bind -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_active_kids -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_suspended_time -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms: Input/output error
File : /sys/class/vtconsole/vtcon0/power/runtime_enabled -VALUE : disabled
File : /sys/class/vtconsole/vtcon0/power/runtime_active_time -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/control -VALUE : auto
File : /sys/class/vtconsole/vtcon0/power/async -VALUE : disabled
File : /sys/class/vtconsole/vtcon0/power/runtime_usage -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_status -VALUE : unsupported
File : /sys/class/vtconsole/vtcon0/uevent -VALUE : 
File : /sys/class/vtconsole/vtcon0/name -VALUE : (S) VGA+
root@debi64:/home/gv/Desktop/PythonTests# for f in $(find /sys/class/vtconsole/vtcon1/ -type f);do echo -e "File : $f \c\c\c";echo -e "-VALUE : \c";cat $f;done
File : /sys/class/vtconsole/vtcon1/bind -VALUE : 1
File : /sys/class/vtconsole/vtcon1/power/runtime_active_kids -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/runtime_suspended_time -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms: Input/output error
File : /sys/class/vtconsole/vtcon1/power/runtime_enabled -VALUE : disabled
File : /sys/class/vtconsole/vtcon1/power/runtime_active_time -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/control -VALUE : auto
File : /sys/class/vtconsole/vtcon1/power/async -VALUE : disabled
File : /sys/class/vtconsole/vtcon1/power/runtime_usage -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/runtime_status -VALUE : unsupported
File : /sys/class/vtconsole/vtcon1/uevent -VALUE : 
File : /sys/class/vtconsole/vtcon1/name -VALUE : (M) frame buffer device
  1. Finalmente, vale a pena investigar possíveis recursos automáticos de economia de energia, como as configurações do Xserver DPMS que podem ser ativadas automaticamente em longos períodos de inatividade.

Segunda atualização:

Olhando em volta, descobri que DPMS e outras configurações relacionadas à economia de energia em terminais virtuais podem ser controladas com o comando setterm . No caso de seus terminais virtuais parecerem estar parados, você poderia tentar acordá-los (se este for o caso) enviando um comando setterm --reset para eles. Para enviar um comando do seu regular tty7 para outro tty você precisa usar: setsid bash -c 'exec setterm --reset <> /dev/tty1 >&0 2>&1'
O único problema é que você deve estar logado em tty1.

Para testes, você pode usar setsid bash -c 'exec setterm --reverse on <> /dev/tty1 >&0 2>&1' e enquanto o seu tty1 estiver funcionando, se você mudar para ele com chvt 1 , você poderá observar os resultados (inverter nas cores de troca no terminal - testado e funcionando no Debian).

Além disso, o setterm oferece opções para ativar / desativar a economia de energia usando setterm --powersave off e muito mais (veja man setterm )

    
por 09.12.2016 / 12:13