El kernel de Linux suelta códigos de escaneo de teclado personalizados

16

Tengo un antiguo teclado IBM 122 modelo clave M que estoy adaptando para usar en una computadora moderna. Estoy usando un Teensy 2.0 para codificar y manejar el lado USB de las cosas. Tomé prestado el firmware del proyecto de teclado Humble Hacker ( https://github.com/humblehacker/keyboard ) y agregué las teclas adicionales en la configuración de compilación. Hasta aquí todo bien.

Todas las teclas "normales" funcionan, pero el núcleo parece estar soltando las teclas adicionales ( F13- F24, etc.).

La ejecución /lib/udev/keymap -i input/event0muestra los códigos de escaneo de todas las teclas normales, pero nada para las teclas adicionales.

Ejecutar wiresharkpara capturar paquetes en el puerto USB muestra que el teclado ESTÁ enviando los códigos de escaneo, pero parece que el núcleo los está soltando en principio.

Siento que esto es algo en los controladores del kernel que simplemente no entrega códigos de escaneo que no espera.

Pensaría que habría algún tipo de mapa de claves "maestro" en algún .harchivo en el origen del kernel en algún lugar, pero hasta ahora, no he tenido éxito en mis esfuerzos por encontrarlo.

Vale la pena enfatizar que no estoy preguntando sobre el mapeo de las teclas adicionales en X, como tantas otras antes que yo. Este es un problema de bajo nivel, aparentemente relacionado con el núcleo. Suponga por el momento que no usaré X en absoluto. Lo que necesito es que aparezcan los códigos de escaneo cuando corro /lib/udev/keymap -i, puedo hacer el resto desde allí.

linux kernel linux-kernel keyboard-shortcuts keyboard usuario2543941
fuente
Sé que esto no ayuda pero: ¿Por qué estás usando el Teensy? Ese teclado debería funcionar con un adaptador PS2 / USB directo.
Ricitos
El teclado provenía de un antiguo terminal de IBM, no utiliza un protocolo compatible con PS / 2.
user2543941
Guau. De hecho, podría ser que el conductor no está pasando el evento en (echar un vistazo a la última parte aquí ). Usted podría intentar evtesten lugar de /lib/udev/keymap -i, ¡no sé si eso va a salir nada diferente.
GOLDILOCKS
1
evtest tampoco muestra nada cuando se usan las teclas adicionales.
user2543941
1
Parece que si quieres usar esas teclas, tu proyecto se ha vuelto un poco más grande, jajaja. Lo más difícil de escribir un controlador de teclado va a aprender la API, de lo contrario, no se ven tan complicado. No he hecho ningún material del núcleo desde hace tiempo, pero esto: LDD3 sigue siendo válida para 3.x, creo.
GOLDILOCKS

Respuestas:

1

El núcleo ve los códigos de escaneo extraños y los suelta. Intentaría obtener esos valores de códigos de escaneo y luego actualizar el índice de la base de datos de hardware. Así que en breve el plan es el siguiente:

  • obtener los códigos de la salida dmesg: dmesg debería generar algo como esto cuando se presiona el código de tecla desconocido:

    Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0)

a0 siendo el valor del código.

  • crear un archivo de asignación de códigos de teclas personalizado. Los ejemplos y la ayuda están en el archivo predeterminado
    ( /usr/lib/udev/hwdb.d/60-keyboard.hwdbpara Arch, puede ser diferente en otras distribuciones).

  • Actualice y active la base de datos de hardware ejecutando los comandos:

    > udevadm hwdb --update
> udevadm trigger /dev/input/eventXX

donde eventXXcorresponde a su teclado (puede obtenerlo ejecutando evtest). También puede reiniciar en lugar de disparar.

Busque en la wiki de Arch y en el archivo de asignación de códigos de teclas predeterminado para obtener una descripción más detallada (o en su documentación de distribución si no es Arch).

Este es el método confiable y simple, hace que el mapeo en el nivel del kernel funcione, sea cual sea el servidor de visualización, DE, etc.

xbob
fuente