teclas de remapeamento rígido do teclado?

Estou tentando encontrar uma maneira de remapear as teclas do teclado com força.
Eu tentei usar xmodmap e setxkbmap, mas eles não funcionam para um aplicativo específico. Tais comandos funcionam para outros aplicativos / janelas normais no X tho.

Eu acho que o aplicativo pode estar lendo os dados brutos do teclado e ignorando a entrada X?

Então, como remapear chaves sem usar xmodmap e setxkbmap? se for possível fazê-lo usando algum software.

Também tentei xkeycaps, xkbcomp, mas não tentei o loadkeys, pois está sendo executado no X.

Descobri aqui que poderia tentar "setkeycodes , porque depois de atribuir o código da chave do kernel, o botão deve funcionar no xorg" , mas também descobri que "você não pode usar 'setkeycodes' nos teclados USB" " , é o meu caso (estou interessado em alguém faz funcionar no ps2, pois acho que poderia usar um adaptador).

Isso parecia promissor "Mapear scancodes para códigos-chave" , mas após alguns testes nada mudou, eis aqui:
Encontrei o código-chave "36" (tecla "j") na vt1 com o showkey
scancode "7e" (teclado ".") Em vt1 comshowkey --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 .: também não funcionou com: KEYBOARD_KEY_7e=j

Algumas maneiras mais alternativas (por @ vinc17) de encontrar as chaves:
evtest /dev/input/by-id/... ou
input-kbd 3(coloque o índice de identificação encontrado em ls -l /dev/input/by-id/*ex. Event3)

PS .: * Se você estiver interessado em testar a si mesmo, o tópico relacionado ao aplicativo é o seguinte: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ Os problemas que têm são os mesmos: algumas chaves (KP_Decimal, DownArrow, UpArrow, RightArrow) são ignoradas e consideradas todas com o mesmo valor "0x00"

Primeiro, encontre o scancode da chave que precisa ser remapeada, por exemplo, com o evtestutilitário. Uma linha como a seguinte (com MSC_SCANela) deve ser impressa:

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

seguido por um segundo, fornecendo o código da chave atual. Se não MSC_SCANhouver saída de linha, isso ocorre devido a um bug no driver do kernel, mas o scancode ainda pode ser encontrado com o input-kbdutilitário; evtestdeve ter fornecido o código da chave, para que seja fácil encontrar a linha correspondente na input-kbdsaída (por exemplo, usando grep).

Depois que os scancodes das chaves a serem remapeadas forem determinados, crie um arquivo como o que /etc/udev/hwdb.d/98-custom-keyboard.hwdbcontém os remapeamentos. O início do arquivo /lib/udev/hwdb.d/60-keyboard.hwdbfornece algumas informações. No meu caso (que funciona), tenho:

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 do udev 220, eu tinha que usar keyboard:usb:v05ACp0221*para a primeira linha.)

A evdev:sequência deve estar no início da linha. Observe que as letras no fornecedor e na ID do produto devem ser maiúsculas. Cada KEYBOARD_KEY_configuração deve ter exatamente um espaço antes (nota: uma linha sem espaços exibirá uma mensagem de erro e uma linha com dois espaços será ignorada silenciosamente nas versões antigas do udev). KEYBOARD_KEY_é seguido pelo scancode em hexadecimal (como o que tanto evteste input-kbddar). Valores válidos poderiam ser obtidos a partir da evtestsaída ou input-kbdsaída, ou mesmo do /usr/include/linux/input.harquivo: por exemplo, KEY_102NDdaria 102nd(removendo KEY_e convertendo para letras minúsculas), que usei acima.

Após o arquivo ser salvo, digite:

udevadm hwdb --update

para (re) criar o banco de dados /etc/udev/hwdb.bin(você pode verificar seu carimbo de data / hora). Então,

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

levará em consideração as novas configurações. Você pode verificar com evtest.

Em 2014, o udev lançado continha informações incompletas / com erros /lib/udev/hwdb.d/60-keyboard.hwdb, mas você pode ver a versão mais recente do arquivo e / ou meu relatório de erros e discussão sobre os problemas de documentação e espaçamento.

Se isso não funcionar, o problema poderá ser encontrado após aumentar temporariamente o nível de log de udevdcom udevadm control(consulte a página do manual udevadm (8) para obter detalhes).

Para udevversões antigas como 204, esse método ainda deve funcionar.