Encuentra el dispositivo responsable

Question

Tuve el mismo problema de que se activaba y desactivaba el modo avión (al menos al mover la tapa).

dispositivo: Laptop HP HP Spectre x360 2 en 1 14-ef2xxx
con teclado alemán
Ubuntu 22.04 LTS

La asignación de códigos de escaneo e057 y e058 al código clave 240 no ayudó. Usando

sudo showkey

y mover la tapa muestra que la tecla 247 (que es el modo avión en mi máquina) se presiona y suelta si la tapa cruza ciertos ángulos, aproximadamente 45 grados con respecto a la mesa (o regazo: D) tanto hacia adelante como hacia atrás.

Sin embargo, repitiendo el mismo procedimiento con

sudo showkey -s

muestra que no hay códigos de escaneo activados. Por lo tanto, esto probablemente no se pueda solucionar simplemente asignando algún código de escaneo a algún código clave usando setkeycodes.

Lo arreglé con la ayuda de [1], que es similar a [2]. Seguir este último uno a uno no funcionó para mí. Aparentemente, necesitaba un dispositivo diferente al del autor para que me afectara la asignación de claves.

Pasé mucho tiempo buscando respuestas, prueba y error, y confundiéndome con publicaciones escritas a nivel de expertos. Al menos aprendí algo. Con suerte, para evitarle a usted y a otros esto, trato de hacer que esta solución paso a paso sea lo más amigable posible para los principiantes.

Encuentra el dispositivo responsable

Abra una terminal mediante Ctrl + Alt + T.

Escriba (luego Ingrese)

cat /proc/bus/input/devices

para obtener una lista de dispositivos. El que se llama "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

podría ser responsable, porque tiene rfkill (desactivar todas las radios, es decir, wlan, bluetooth, etc.) como controlador. lo llamaré eldispositivoa partir de aquí.

Obtener los códigos clave

Antes de probar el dispositivo y obtener los códigos clave, instale evtest. Escribe (luego ingresa)

sudo apt install -y evtest

Proporcione su contraseña si se le solicita. Para probar si el dispositivo es responsable y obtener los códigos clave, abra una terminal virtual (en una terminal X normal, básicamente su GUI de Ubuntu, puede hacer que esta prueba sea imposible). A menudo, esto se hace mediante Ctrl + Alt + F1, pero en mi caso, F1 debe reemplazarse por F3. Para volver a X, presione Ctrl + Alt + F2 (en mi caso). En otras máquinas suele aparecer F7. Encontré las claves adecuadas para mí mediante prueba y error.

Proporcione su nombre de usuario y contraseña. Escriba (luego Ingrese)

sudo evtest /dev/input/event17

En mi caso es el evento 17, porque estaba en el campo Controlador del dispositivo, ver arriba. Noté que el número cambia si conecto, por ejemplo, un mouse y un teclado a mi computadora portátil. Por lo tanto, en su caso podría ser un número diferente.

A continuación, cierre y abra la tapa. Salga del modo de prueba de evtest mediante Ctrl + C y salga de la terminal virtual mediante Ctrl + Alt + F2 (en mi caso). En mi pantalla, esto se imprimió durante el 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 ------------

Si desea que esto se imprima en un archivo, diga evtest_output.txt en su directorio de inicio ~, escriba

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

en su lugar, en el paso anterior. Sin embargo, tenga en cuenta que no verá el resultado impreso en la pantalla durante la prueba.

Examinemos el contenido de evtest_output.txt. Primero, nos dice algunas especificaciones del dispositivo y los eventos admitidos. Debajo Testing...hay diez eventos que se imprimieron durante el movimiento de la tapa. Los primeros cinco eventos pertenecen al cierre y los últimos cinco eventos a la apertura de la tapa. Tenga en cuenta que no lo cierro por completo. Una inclinación de unos 45 grados es suficiente para activar el modo avión. Esto confirma que el dispositivo "Intel HID events" es el responsable.

Arreglar con hwdb

Para solucionar este problema usando hwdb, creé el archivo intel-HID-events.hwdb escribiendo en la terminal (luego Enter)

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

Los contenidos que escribí son (en mi caso)

evdev:input:b0019v0000p0000e0000-*
 KEYBOARD_KEY_08=unknown

Los números en la primera línea son los campos bus (0019), proveedor (0000), producto (0000) y versión (0000) del dispositivo (consulte el resultado del cat /proc/us/input/devicesmensaje anterior). El asterisco *que sigue es un marcador de posición para cualquier número de símbolos. Sin embargo, no especifiqué más, como se hace en [1]. Mi razón es que las modalidades del dispositivo parecen cambiar cuando (des)conecto otro hardware, por ejemplo, mi mouse.

Tenga en cuenta la sangría de la segunda línea. La clave 08, que es el valor (después de MSC_SCAN) del primer evento al cerrar o abrir en evtest, está configurada como desconocida.

Guarde con Ctrl + O, Enter y cierre con Ctrl + X. Luego actualice mediante

sudo systemd-hwdb update

sudo udevadm trigger

Esto es de [2].

Mueve la tapa. Ya no debería activar el modo avión. No tuve que hacer estos cambios "permanentes" como se hace en [2]. Después de reiniciar, el problema aún está solucionado. Veamos si la próxima actualización corrige la solución...

¡Espero que esto te ayude a ti o a cualquiera!

Saludos jk

Referencias

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

[2]Cambio del modo avión al cambiar al modo tableta (HP Spectre x360)

Answer 1

Tuve el mismo problema de que se activaba y desactivaba el modo avión (al menos al mover la tapa).

dispositivo: Laptop HP HP Spectre x360 2 en 1 14-ef2xxx
con teclado alemán
Ubuntu 22.04 LTS

La asignación de códigos de escaneo e057 y e058 al código clave 240 no ayudó. Usando

sudo showkey

y mover la tapa muestra que la tecla 247 (que es el modo avión en mi máquina) se presiona y suelta si la tapa cruza ciertos ángulos, aproximadamente 45 grados con respecto a la mesa (o regazo: D) tanto hacia adelante como hacia atrás.

Sin embargo, repitiendo el mismo procedimiento con

sudo showkey -s

muestra que no hay códigos de escaneo activados. Por lo tanto, esto probablemente no se pueda solucionar simplemente asignando algún código de escaneo a algún código clave usando setkeycodes.

Lo arreglé con la ayuda de [1], que es similar a [2]. Seguir este último uno a uno no funcionó para mí. Aparentemente, necesitaba un dispositivo diferente al del autor para que me afectara la asignación de claves.

Pasé mucho tiempo buscando respuestas, prueba y error, y confundiéndome con publicaciones escritas a nivel de expertos. Al menos aprendí algo. Con suerte, para evitarle a usted y a otros esto, trato de hacer que esta solución paso a paso sea lo más amigable posible para los principiantes.

Encuentra el dispositivo responsable

Abra una terminal mediante Ctrl + Alt + T.

Escriba (luego Ingrese)

cat /proc/bus/input/devices

para obtener una lista de dispositivos. El que se llama "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

podría ser responsable, porque tiene rfkill (desactivar todas las radios, es decir, wlan, bluetooth, etc.) como controlador. lo llamaré eldispositivoa partir de aquí.

Obtener los códigos clave

Antes de probar el dispositivo y obtener los códigos clave, instale evtest. Escribe (luego ingresa)

sudo apt install -y evtest

Proporcione su contraseña si se le solicita. Para probar si el dispositivo es responsable y obtener los códigos clave, abra una terminal virtual (en una terminal X normal, básicamente su GUI de Ubuntu, puede hacer que esta prueba sea imposible). A menudo, esto se hace mediante Ctrl + Alt + F1, pero en mi caso, F1 debe reemplazarse por F3. Para volver a X, presione Ctrl + Alt + F2 (en mi caso). En otras máquinas suele aparecer F7. Encontré las claves adecuadas para mí mediante prueba y error.

Proporcione su nombre de usuario y contraseña. Escriba (luego Ingrese)

sudo evtest /dev/input/event17

En mi caso es el evento 17, porque estaba en el campo Controlador del dispositivo, ver arriba. Noté que el número cambia si conecto, por ejemplo, un mouse y un teclado a mi computadora portátil. Por lo tanto, en su caso podría ser un número diferente.

A continuación, cierre y abra la tapa. Salga del modo de prueba de evtest mediante Ctrl + C y salga de la terminal virtual mediante Ctrl + Alt + F2 (en mi caso). En mi pantalla, esto se imprimió durante el 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 ------------

Si desea que esto se imprima en un archivo, diga evtest_output.txt en su directorio de inicio ~, escriba

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

en su lugar, en el paso anterior. Sin embargo, tenga en cuenta que no verá el resultado impreso en la pantalla durante la prueba.

Examinemos el contenido de evtest_output.txt. Primero, nos dice algunas especificaciones del dispositivo y los eventos admitidos. Debajo Testing...hay diez eventos que se imprimieron durante el movimiento de la tapa. Los primeros cinco eventos pertenecen al cierre y los últimos cinco eventos a la apertura de la tapa. Tenga en cuenta que no lo cierro por completo. Una inclinación de unos 45 grados es suficiente para activar el modo avión. Esto confirma que el dispositivo "Intel HID events" es el responsable.

Arreglar con hwdb

Para solucionar este problema usando hwdb, creé el archivo intel-HID-events.hwdb escribiendo en la terminal (luego Enter)

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

Los contenidos que escribí son (en mi caso)

evdev:input:b0019v0000p0000e0000-*
 KEYBOARD_KEY_08=unknown

Los números en la primera línea son los campos bus (0019), proveedor (0000), producto (0000) y versión (0000) del dispositivo (consulte el resultado del cat /proc/us/input/devicesmensaje anterior). El asterisco *que sigue es un marcador de posición para cualquier número de símbolos. Sin embargo, no especifiqué más, como se hace en [1]. Mi razón es que las modalidades del dispositivo parecen cambiar cuando (des)conecto otro hardware, por ejemplo, mi mouse.

Tenga en cuenta la sangría de la segunda línea. La clave 08, que es el valor (después de MSC_SCAN) del primer evento al cerrar o abrir en evtest, está configurada como desconocida.

Guarde con Ctrl + O, Enter y cierre con Ctrl + X. Luego actualice mediante

sudo systemd-hwdb update

sudo udevadm trigger

Esto es de [2].

Mueve la tapa. Ya no debería activar el modo avión. No tuve que hacer estos cambios "permanentes" como se hace en [2]. Después de reiniciar, el problema aún está solucionado. Veamos si la próxima actualización corrige la solución...

¡Espero que esto te ayude a ti o a cualquiera!

Saludos jk

Referencias

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

[2]Cambio del modo avión al cambiar al modo tableta (HP Spectre x360)

Encuentra el dispositivo responsable

Respuesta1

Encuentra el dispositivo responsable

Obtener los códigos clave

Arreglar con hwdb

información relacionada