i3: Como usar as teclas de mídia que aparecem em dispositivos de entrada separados?

1

Instalei o gerenciador de janelas do i3 ao lado da área de trabalho do GNOME no Ubuntu-GNOME 16.04. Estou tendo problemas para usar minhas teclas de mídia com um teclado Logitech G610.

Eu tenho o seguinte no meu arquivo ~/.config/i3/config :

bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ +5%
bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ -5%
bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute 0 toggle

e confirmaram que esses comandos funcionam no terminal. O problema que estou vendo é que os eventos de pressionamento de tecla XF86AudioRaiseVolume etc não estão sendo registrados.

Se eu usar xev -event keyboard para tentar ver os códigos de teclas, quando eu pressionar as teclas multimídia, tudo o que eu obtenho é o seguinte:

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  1   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

e nenhum código é reportado como para outras chaves. No entanto, usando sudo showkey -k , recebo o seguinte, que são os valores esperados:

keycode 113 press
keycode 113 release
keycode 115 press
keycode 115 release
keycode 114 press
keycode 114 release

executando xinput , vejo o seguinte

⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech MX Master                        id=12   [slave  pointer  (2)]
⎜   ↳ AlpsPS/2 ALPS DualPoint TouchPad          id=15   [slave  pointer  (2)]
⎜   ↳ AlpsPS/2 ALPS DualPoint Stick             id=16   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ Logitech Gaming Keyboard G610             id=10   [slave  keyboard (3)]
    ↳ Logitech Gaming Keyboard G610             id=11   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=13   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=14   [slave  keyboard (3)]
    ↳ DELL Wireless hotkeys                     id=17   [slave  keyboard (3)]

em que o teclado da Logitech é exibido como dois dispositivos. Executando xinput list-props 10 e xinput list-props 11 Vejo que a primeira listagem é mapeada para /dev/input/event8 , enquanto a segunda mapeia para /dev/input/event9 .

Se eu executar xinput test 10 , vejo que a primeira listagem do meu teclado responde a todas as teclas normais do teclado, mas não às teclas de mídia, enquanto xinput test 11 responde apenas às chaves de mídia:

key press   121 
key release 121 
key press   123 
key release 123 
key press   122 
key release 122

(Eles estão desativados em 8 da saída showkey , mas aparentemente isso é esperado. Além disso, esses valores correspondem à saída do mapeamento por xmodmap -pke , ou seja, keycode 121 = XF86AudioMute NoSymbol XF86AudioMute ). A execução de sudo evtest /dev/input/event8 e sudo evtest /dev/input/event9 produz resultados semelhantes.

Então, meu entendimento do processo entre keypress e handling é bem confuso, mas parece que talvez o fato de chaves normais e media keys estarem em diferentes dispositivos de entrada esteja impedindo que os eventos keypress da mídia passem para a sessão X (como evidenciado por não aparecer para xev ?) e, portanto, não passar para i3? Isso funciona bem para a área de trabalho do GNOME, então há algo que eu preciso configurar para fazê-los funcionar para o i3? Eu estou em uma perda de como proceder a partir daqui, qualquer ajuda seria muito apreciada.

EDITAR

Eu originalmente tinha citações em torno dos comandos no meu arquivo ~/.config/i3/config , mas isso não funciona. Eu editei acima para corrigir, mas essa não foi a raiz do problema.

    
por dpkoch 17.09.2018 / 20:39

2 respostas

1

Com base nas informações fornecidas na resposta anterior , corri ps e notei que gnome-session estava em execução apesar de eu não ter logado na área de trabalho do GNOME desde a inicialização e ter feito o login no i3. Minha suspeita era de que a sessão do gnome estava roubando os eventos, mas a falta de mapeamento desses atalhos de teclado nas configurações do gnome não parecia mudar nada.

Minha solução foi inicializar diretamente em uma sessão tty seguindo as instruções aqui , para que gnome-session não seja iniciado. Eu criei o arquivo ~/.xinitrc contendo a única linha exec i3 , depois do boot efetuei o login no terminal tty e execute startx para iniciar o i3. Com esse método, o gnome não está em execução e minhas teclas de mídia agora funcionam.

    
por 26.09.2018 / 00:47
0

Resposta parcial:

O teclado exibido como dois dispositivos não é um problema. Ambos os dispositivos são atribuídos ao Virtual Core Keyboard, portanto, ambos os dispositivos devem produzir os eventos principais de chave adequados.

O evento MappingNotify pode ser uma indicação de que algum aplicativo está reagindo às chaves de mídia. Em particular, se você obtiver FocusOut e FocusIn eventos que você não nos mostrou, algum outro aplicativo estará agindo com certeza nesses casos.

Agora, este pode ser o gerenciador de janelas do i3 com suas chaves configuradas ou pode ser outra coisa. Então, a primeira coisa a testar é remover ou comentar suas ligações do i3, testar novamente e ver se você ainda recebe os eventos de Mapeamento / Foco.

Se sim, o próximo passo é descobrir qual aplicativo está roubando. Use ps , xlsclients etc. para reduzi-lo. Uma maneira é matar / desativar os aplicativos até que eles não sejam mais roubados.

    
por 17.09.2018 / 22:45