Encontre o dispositivo responsável

Question

Tive o mesmo problema de que o modo avião seria ativado e desativado (pelo menos ao mover a tampa).

dispositivo: Laptop HP HP Spectre x360 2 em 1 14-ef2xxx
com teclado alemão
Ubuntu 22.04LTS

Mapear os scancodes e057 e e058 para o código-chave 240 não ajudou. Usando

sudo showkey

e mover a tampa mostra que a tecla 247 (que é o modo avião na minha máquina) é pressionada e liberada se a tampa cruzar certos ângulos, aproximadamente 45 graus em relação à mesa (ou volta: D) na direção para frente ou para trás.

Porém, repetindo o mesmo procedimento com

sudo showkey -s

mostra que nenhum scancode está ativado. Portanto, isso provavelmente não pode ser corrigido apenas mapeando algum scancode para algum código-chave usando setkeycodes.

Eu consertei com a ajuda de [1], que é semelhante a [2]. Seguir o último individualmente não funcionou para mim. Aparentemente, eu precisava de um dispositivo diferente do autor para ser afetado pelo mapeamento de teclas.

Passei muito tempo procurando respostas, tentativa e erro, e ficando confuso com postagens escritas por especialistas. Pelo menos aprendi alguma coisa. Para poupar você e outras pessoas disso, tento tornar esta solução passo a passo o mais amigável possível para iniciantes.

Encontre o dispositivo responsável

Abra um terminal via Ctrl + Alt + T.

Digite (depois digite)

cat /proc/bus/input/devices

para obter uma lista de dispositivos. Aquele chamado "eventos Intel HID",

I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name="Intel HID events"
P: Phys=
S: Sysfs=/devices/platform/INTC1070:00/input/input35
U: Uniq=
H: Handlers=rfkill kbd event17 
B: PROP=0
B: EV=13
B: KEY=1000300000000 5000004000 1e294000000020 0
B: MSC=10

poderia ser o responsável, pois possui rfkill (desativar todos os rádios, ou seja, wlan, bluetooth etc.) como manipulador. vou chamá-lo dedispositivodaqui em diante.

Obtenha os códigos-chave

Antes de testar o dispositivo e obter os códigos de acesso, instale o evtest. Digite (depois digite)

sudo apt install -y evtest

Forneça sua senha, se solicitado. Para testar se o dispositivo é responsável e obter os códigos-chave, abra um terminal virtual (em um terminal X normal, basicamente sua GUI do Ubuntu, pode tornar este teste impossível). Muitas vezes isso é feito via Ctrl + Alt + F1, mas no meu caso F1 tem que ser substituído por F3. Para voltar ao X, pressione Ctrl + Alt + F2 (no meu caso). Em outras máquinas, muitas vezes parece ser F7. Encontrei as chaves certas para mim por tentativa e erro.

Forneça seu nome de usuário e senha. Digite (depois digite)

sudo evtest /dev/input/event17

No meu caso é o evento17, pois estava no campo Handler do dispositivo, veja acima. Percebi que o número muda se eu conectar, por exemplo, um mouse e um teclado ao meu laptop. Portanto, no seu caso, pode ser um número diferente.

Em seguida, feche e abra a tampa. Saia do modo de teste do evtest via Ctrl + C e saia do terminal virtual via Ctrl + Alt + F2 (no meu caso). Na minha tela, isso foi impresso durante o evtest:

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Intel HID events"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 69 (KEY_NUMLOCK)
    Event code 102 (KEY_HOME)
    Event code 104 (KEY_PAGEUP)
    Event code 107 (KEY_END)
    Event code 109 (KEY_PAGEDOWN)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 116 (KEY_POWER)
    Event code 142 (KEY_SLEEP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 166 (KEY_STOPCD)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 240 (KEY_UNKNOWN)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1684340717.813043, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1684340717.813043, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1684340717.813043, -------------- SYN_REPORT ------------
Event: time 1684340717.813055, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1684340717.813055, -------------- SYN_REPORT ------------
Event: time 1684340721.308956, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1684340721.308956, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1684340721.308956, -------------- SYN_REPORT ------------
Event: time 1684340721.308963, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1684340721.308963, -------------- SYN_REPORT ------------

Se você quiser que isso seja impresso em um arquivo, diga evtest_output.txt em seu diretório inicial ~, digite

sudo evtest /dev/input/event17 > ~/evtest_output.txt

em vez disso, na etapa acima. Observe que você não verá a saída impressa na tela durante o teste.

Vamos examinar o conteúdo de evtest_output.txt. Primeiro, ele nos informa algumas especificações do dispositivo e os eventos suportados. Abaixo Testing...estão dez eventos que foram impressos durante o movimento da tampa. Os primeiros cinco eventos pertencem ao fechamento e os últimos cinco eventos à abertura da tampa. Observe que não o fecho completamente. Uma inclinação de cerca de 45 graus é suficiente para acionar o modo avião. Isso confirma que o dispositivo "Intel HID events" é o responsável.

Corrigir com hwdb

Para corrigir esse problema usando hwdb, criei o arquivo intel-HID-events.hwdb digitando no terminal (depois Enter)

sudo nano /etc/udev/hwdb.d/intel-HID-events.hwdb

O conteúdo que digitei é (no meu caso)

evdev:input:b0019v0000p0000e0000-*
 KEYBOARD_KEY_08=unknown

Os números na primeira linha são os campos barramento (0019), fornecedor (0000), produto (0000) e versão (0000) do dispositivo (veja a saída do cat /proc/us/input/devicesprompt acima). O asterisco *a seguir é um espaço reservado para qualquer número de símbolos. No entanto, não especifiquei mais, como é feito em [1]. Minha razão é que as modalidades do dispositivo parecem mudar quando eu (des)conecto outro hardware, por exemplo, meu mouse.

Observe o recuo da segunda linha. A chave 08, que é o valor (após MSC_SCAN) do primeiro evento ao fechar ou abrir no evtest, é definida como desconhecida.

Salve com Ctrl + O, Enter e feche com Ctrl + X. Em seguida, atualize via

sudo systemd-hwdb update

sudo udevadm trigger

Isto é de [2].

Mova a tampa. Não deve mais acionar o modo avião. Não precisei tornar essas alterações "permanentes" como é feito em [2]. Após a reinicialização, o problema ainda foi corrigido. Vamos ver se a próxima atualização resolve a correção...

Espero que isso ajude você ou alguém aí!

Felicidades, brincadeira

Referências

[1]https://yulistic.gitlab.io/2017/12/linux-keymapping-with-udev-hwdb/

[2]Modo avião alternando ao mudar para o modo tablet (HP spectre x360)

Answer 1

Tive o mesmo problema de que o modo avião seria ativado e desativado (pelo menos ao mover a tampa).

dispositivo: Laptop HP HP Spectre x360 2 em 1 14-ef2xxx
com teclado alemão
Ubuntu 22.04LTS

Mapear os scancodes e057 e e058 para o código-chave 240 não ajudou. Usando

sudo showkey

e mover a tampa mostra que a tecla 247 (que é o modo avião na minha máquina) é pressionada e liberada se a tampa cruzar certos ângulos, aproximadamente 45 graus em relação à mesa (ou volta: D) na direção para frente ou para trás.

Porém, repetindo o mesmo procedimento com

sudo showkey -s

mostra que nenhum scancode está ativado. Portanto, isso provavelmente não pode ser corrigido apenas mapeando algum scancode para algum código-chave usando setkeycodes.

Eu consertei com a ajuda de [1], que é semelhante a [2]. Seguir o último individualmente não funcionou para mim. Aparentemente, eu precisava de um dispositivo diferente do autor para ser afetado pelo mapeamento de teclas.

Passei muito tempo procurando respostas, tentativa e erro, e ficando confuso com postagens escritas por especialistas. Pelo menos aprendi alguma coisa. Para poupar você e outras pessoas disso, tento tornar esta solução passo a passo o mais amigável possível para iniciantes.

Encontre o dispositivo responsável

Abra um terminal via Ctrl + Alt + T.

Digite (depois digite)

cat /proc/bus/input/devices

para obter uma lista de dispositivos. Aquele chamado "eventos Intel HID",

I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name="Intel HID events"
P: Phys=
S: Sysfs=/devices/platform/INTC1070:00/input/input35
U: Uniq=
H: Handlers=rfkill kbd event17 
B: PROP=0
B: EV=13
B: KEY=1000300000000 5000004000 1e294000000020 0
B: MSC=10

poderia ser o responsável, pois possui rfkill (desativar todos os rádios, ou seja, wlan, bluetooth etc.) como manipulador. vou chamá-lo dedispositivodaqui em diante.

Obtenha os códigos-chave

Antes de testar o dispositivo e obter os códigos de acesso, instale o evtest. Digite (depois digite)

sudo apt install -y evtest

Forneça sua senha, se solicitado. Para testar se o dispositivo é responsável e obter os códigos-chave, abra um terminal virtual (em um terminal X normal, basicamente sua GUI do Ubuntu, pode tornar este teste impossível). Muitas vezes isso é feito via Ctrl + Alt + F1, mas no meu caso F1 tem que ser substituído por F3. Para voltar ao X, pressione Ctrl + Alt + F2 (no meu caso). Em outras máquinas, muitas vezes parece ser F7. Encontrei as chaves certas para mim por tentativa e erro.

Forneça seu nome de usuário e senha. Digite (depois digite)

sudo evtest /dev/input/event17

No meu caso é o evento17, pois estava no campo Handler do dispositivo, veja acima. Percebi que o número muda se eu conectar, por exemplo, um mouse e um teclado ao meu laptop. Portanto, no seu caso, pode ser um número diferente.

Em seguida, feche e abra a tampa. Saia do modo de teste do evtest via Ctrl + C e saia do terminal virtual via Ctrl + Alt + F2 (no meu caso). Na minha tela, isso foi impresso durante o evtest:

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Intel HID events"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 69 (KEY_NUMLOCK)
    Event code 102 (KEY_HOME)
    Event code 104 (KEY_PAGEUP)
    Event code 107 (KEY_END)
    Event code 109 (KEY_PAGEDOWN)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 116 (KEY_POWER)
    Event code 142 (KEY_SLEEP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 166 (KEY_STOPCD)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 240 (KEY_UNKNOWN)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1684340717.813043, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1684340717.813043, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1684340717.813043, -------------- SYN_REPORT ------------
Event: time 1684340717.813055, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1684340717.813055, -------------- SYN_REPORT ------------
Event: time 1684340721.308956, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1684340721.308956, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1684340721.308956, -------------- SYN_REPORT ------------
Event: time 1684340721.308963, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1684340721.308963, -------------- SYN_REPORT ------------

Se você quiser que isso seja impresso em um arquivo, diga evtest_output.txt em seu diretório inicial ~, digite

sudo evtest /dev/input/event17 > ~/evtest_output.txt

em vez disso, na etapa acima. Observe que você não verá a saída impressa na tela durante o teste.

Vamos examinar o conteúdo de evtest_output.txt. Primeiro, ele nos informa algumas especificações do dispositivo e os eventos suportados. Abaixo Testing...estão dez eventos que foram impressos durante o movimento da tampa. Os primeiros cinco eventos pertencem ao fechamento e os últimos cinco eventos à abertura da tampa. Observe que não o fecho completamente. Uma inclinação de cerca de 45 graus é suficiente para acionar o modo avião. Isso confirma que o dispositivo "Intel HID events" é o responsável.

Corrigir com hwdb

Para corrigir esse problema usando hwdb, criei o arquivo intel-HID-events.hwdb digitando no terminal (depois Enter)

sudo nano /etc/udev/hwdb.d/intel-HID-events.hwdb

O conteúdo que digitei é (no meu caso)

evdev:input:b0019v0000p0000e0000-*
 KEYBOARD_KEY_08=unknown

Os números na primeira linha são os campos barramento (0019), fornecedor (0000), produto (0000) e versão (0000) do dispositivo (veja a saída do cat /proc/us/input/devicesprompt acima). O asterisco *a seguir é um espaço reservado para qualquer número de símbolos. No entanto, não especifiquei mais, como é feito em [1]. Minha razão é que as modalidades do dispositivo parecem mudar quando eu (des)conecto outro hardware, por exemplo, meu mouse.

Observe o recuo da segunda linha. A chave 08, que é o valor (após MSC_SCAN) do primeiro evento ao fechar ou abrir no evtest, é definida como desconhecida.

Salve com Ctrl + O, Enter e feche com Ctrl + X. Em seguida, atualize via

sudo systemd-hwdb update

sudo udevadm trigger

Isto é de [2].

Mova a tampa. Não deve mais acionar o modo avião. Não precisei tornar essas alterações "permanentes" como é feito em [2]. Após a reinicialização, o problema ainda foi corrigido. Vamos ver se a próxima atualização resolve a correção...

Espero que isso ajude você ou alguém aí!

Felicidades, brincadeira

Referências

[1]https://yulistic.gitlab.io/2017/12/linux-keymapping-with-udev-hwdb/

[2]Modo avião alternando ao mudar para o modo tablet (HP spectre x360)

Encontre o dispositivo responsável

Responder1

Encontre o dispositivo responsável

Obtenha os códigos-chave

Corrigir com hwdb

informação relacionada