teclas de reasignación del teclado?

19

Estoy tratando de encontrar una manera de reasignar las teclas del teclado con fuerza.
Intenté usar xmodmap y setxkbmap, pero no funcionan para una aplicación específica. Dichos comandos funcionan para otras ventanas / aplicaciones normales en X tho.

¿Creo que la aplicación puede estar leyendo los datos sin procesar del teclado e ignorando la entrada X?

Entonces, ¿cómo reasignar las teclas sin usar xmodmap y setxkbmap? si alguna vez se puede hacer usando algún software.

También probé xkeycaps, xkbcomp, pero no probé loadkeys, ya que se ejecuta en X.

Encontré aquí que podía intentarlo setkeycodes, "porque después de asignar el código de clave del núcleo, el botón debería funcionar en xorg" , pero también descubrí que "no se pueden usar 'setkeycodes' en teclados USB" , ese es mi caso (estoy interesado en el caso alguien lo hace funcionar en ps2 ya que creo que podría usar un adaptador).

Esto parecía prometedor "Asignar códigos de escaneo a códigos de teclas" , pero después de algunas pruebas nada cambió, aquí están:
Encontré el código de clave "36" (tecla "j") en vt1 con el código de showkey
escaneo "7e" (teclado ".") En vt1 conshowkey --scancodes

$cat >/etc/udev/hwdb.d/90-custom-keyboard.hwdb
keyboard:usb:v*p*
keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
 KEYBOARD_KEY_7e=36
$udevadm hwdb --update #updates file: /lib/udev/hwdb.bin
$udevadm trigger #should apply the changes but nothing happened
$cat /lib/udev/hwdb.bin |egrep "KEYBOARD_KEY_7e.{10}" -ao
KEYBOARD_KEY_7eleftmeta
$#that cat on hwdb.bin did not change after the commands..

Obs .: tampoco funcionó con: KEYBOARD_KEY_7e=j

Algunas formas más alternativas (por @ vinc17) para encontrar las claves:
evtest /dev/input/by-id/... o
input-kbd 3(coloque el índice de identificación encontrado en ls -l /dev/input/by-id/*ex. Event3)

PD .: * Si está interesado en probarse a sí mismo, el hilo relacionado para la aplicación es este: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ Los problemas I tienen son las mismas: algunas claves (KP_Decimal, DownArrow, UpArrow, RightArrow) se ignoran y se consideran todas con el mismo valor "0x00"

Poder de acuario
fuente
El archivo actualizado debe ser /etc/udev/hwdb.bin, no /lib/udev/hwdb.bin. Pero aunque este archivo se actualiza correctamente, esto tampoco funciona para mí, incluso después de un reinicio. Quizás algo falta en la documentación. Acerca de esto: bugs.freedesktop.org/show_bug.cgi?id=82311
vinc17
@ vinc17 eso es realmente interesante, tan pronto como pueda lo intentaré nuevamente, creo que tenemos que encontrar ese archivo de configuración e intentar imitarlo, ¡gracias!
Acuario Power
1
Mi problema se debió al hecho de que las líneas KEYBOARD_KEY_ comenzaron con 2 espacios en lugar de uno solo (¡esto no fue documentado y no recibí mensajes de error!). No sé por ti, pero con mi teclado USB, showkey --scancodesno da los códigos de escaneo que udev espera (los valores son diferentes); la input-kbdutilidad proporciona los códigos de escaneo correctos.
vinc17
1
La evtestutilidad también debe proporcionarle los códigos de escaneo correctos: después de escribir una clave, debe obtener 2 líneas y la primera debe terminar con algo del formulario code 4 (MSC_SCAN), value xxx, donde xxxestá el código de escaneo. Pero el controlador de mi teclado tiene errores, y no obtengo esta MSC_SCANlínea para algunas teclas que quería reasignar. Es por eso que utilicé input-kbd, que enumera todos los códigos de escaneo para el dispositivo seleccionado.
vinc17
1
He publicado información detallada en una respuesta. Ahora, no estoy seguro de que 36 o 7002c funcione como un valor. Creo que necesitas el identificador del código clave. Mira mi respuesta.
vinc17

Respuestas:

17

Primero encuentre el código de escaneo de la clave que necesita reasignarse, por ejemplo, con la evtestutilidad. Se MSC_SCANdebe generar una línea como la siguiente (con ella):

Event: time 1417131619.686259, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70068

seguido de un segundo que proporciona el código clave actual. Si no MSC_SCANse emite ninguna línea, esto se debe a un error del controlador del kernel, pero el código de escaneo todavía se puede encontrar con la input-kbdutilidad; evtestdebería haber proporcionado el código clave, de modo que debería ser fácil encontrar la línea correspondiente en la input-kbdsalida (por ejemplo, usando grep).

Una vez que se hayan determinado los códigos de escaneo de las claves que se reasignarán, cree un archivo como el que /etc/udev/hwdb.d/98-custom-keyboard.hwdbcontiene las reasignaciones. El comienzo del archivo /lib/udev/hwdb.d/60-keyboard.hwdbda alguna información. En mi caso (que funciona), tengo:

evdev:input:b0003v05ACp0221*
 KEYBOARD_KEY_70035=102nd       # Left to z: backslash bar
 KEYBOARD_KEY_70064=grave       # Left to 1: grave notsign
 KEYBOARD_KEY_70068=insert      # F13: Insert

(Antes de udev 220, tenía que usar keyboard:usb:v05ACp0221*para la primera línea).

La evdev:cadena debe estar al principio de la línea. Tenga en cuenta que las letras en el proveedor y la identificación del producto deben ser mayúsculas. Cada KEYBOARD_KEY_configuración debe tener exactamente un espacio antes (nota: una línea sin espacios dará un mensaje de error, y una línea con dos espacios se ignoró en silencio con las versiones antiguas de udev). KEYBOARD_KEY_es seguido por el código de escaneo en hexadecimal (como lo que ambos evtesty input-kbddar). Los valores válidos se pueden obtener de la evtestsalida o la input-kbdsalida, o incluso del /usr/include/linux/input.harchivo: por ejemplo, KEY_102NDdaría102nd (quitando KEY_y convirtiendo a minúsculas), que utilicé anteriormente.

Después de guardar el archivo, escriba:

udevadm hwdb --update

para (re) construir la base de datos /etc/udev/hwdb.bin(puede verificar su marca de tiempo). Luego,

udevadm trigger --sysname-match="event*"

tendrá en cuenta la nueva configuración. Puedes consultar conevtest .

En 2014, el udev publicado contenía información incompleta / con errores /lib/udev/hwdb.d/60-keyboard.hwdb, pero puede consultar la última versión de desarrollo del archivo y / o mi informe y discusión de errores sobre la documentación y los problemas de espacio.

Si esto no funciona, el problema podría encontrarse después de aumentar temporalmente el nivel de registro de udevd with udevadm control(consulte la página del comando man udevadm (8) para obtener más detalles).

Para udevversiones antiguas como 204, este método aún debería funcionar.

vinc17
fuente
Cuando ejecuto los comandos udevadm, el archivo que se actualiza es /lib/udev/hwdb.bin, miré blessy KEYBOARD_KEY_70085aparece al final. Creo que ubuntu 14.04 está configurado (¿protegido?) De esta manera. Probé udevadm control --log-priority=debug. basado en lsusb(045e: 0750) me gusta mi teclado keyboard:usb:v045ep0750*, pero también lo intenté keyboard:usb:v*p*. Supongo que esto /etc/udev/hwdb.bindebería actualizarse, pero ni siquiera existe.
Acuario Power
Como leí aquí , podría ser como si estuviera usando este comando udevadm hwdb --usr --update, a pesar de que no lo estaba.
Acuario Power
Después udevadm hwdb --updatehe copiado /lib/udev/hwdb.bina /etc/udev/hwdb.biny corrió strace udevadm trigger --sysname-match="event*"y el archivo hwdb.binparece no haber sido leído por ella (si es como funciona este).
Acuario Power
1
@AquariusPower Sí, puede haber un error específico de Ubuntu (estoy usando Debian / inestable). Para ver si la base de datos se lee al hacerlo udevadm trigger ..., vea mi prueba aquí . Tenga en cuenta que antes de ejecutar udevadm trigger ..., debe asegurarse de que se haya actualizado el tiempo de modificación del archivo; de lo contrario, el tiempo de acceso no se actualizará cuando se lea el archivo.
vinc17
1
@AquariusPower udevadm --version: 215 (y versión del paquete udev: 215-7). Gracias a udevadm trigger ..., no debería necesitar reiniciar (a menos que desee eliminar la configuración, AFAIK). Pero es posible que desee probar un reinicio para ver si hay algún efecto.
vinc17