tasti di rimappatura della tastiera?

Sto cercando di trovare un modo per rimappare i tasti della tastiera con forza.
Ho provato ad usare xmodmap e setxkbmap, ma non funzionano per un'applicazione specifica. Tali comandi funzionano per altre normali finestre / applicazioni su X tho.

Penso che l'applicazione potrebbe leggere i dati grezzi della tastiera e ignorare l'input X?

Quindi, come rimappare le chiavi senza usare xmodmap e setxkbmap? se è mai possibile farlo utilizzando alcuni software.

Ho anche provato xkeycaps, xkbcomp, ma non ho provato loadkeys, poiché è in esecuzione su X.

Ho scoperto qui che potevo provare "setkeycodes , perché dopo aver assegnato il keycode del kernel il pulsante dovrebbe funzionare in xorg" , ma ho anche scoperto che "non puoi usare 'setkeycodes' sulle tastiere USB" , questo è il mio caso (sono interessato al caso qualcuno lo fa funzionare su ps2 perché penso che potrei usare un adattatore).

Questo sembrava promettente "Mappa scancodes a keycodes" , ma dopo alcuni test non è cambiato nulla, eccoli qui:
ho trovato il keycode "36" ("j" key) su vt1 con showkey
ho trovato scancode "7e" (tastiera ".") Su 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 .: non ha funzionato neanche con: KEYBOARD_KEY_7e=j

Altri modi alternativi (di @ vinc17) per trovare le chiavi:
evtest /dev/input/by-id/... oppure
input-kbd 3(metti l'indice id trovato ls -l /dev/input/by-id/*da ex. Event3)

PS .: * Se sei interessato a testare te stesso, il thread correlato per l'applicazione è questo: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ I problemi I sono uguali: alcune chiavi (KP_Decimal, DownArrow, UpArrow, RightArrow) vengono ignorate e considerate tutte con lo stesso valore lì "0x00"

— Potenza dell'acquario
fonte

Il file aggiornato dovrebbe essere /etc/udev/hwdb.bin, non /lib/udev/hwdb.bin. Ma sebbene questo file sia aggiornato correttamente, non funziona neanche per me, anche dopo un riavvio. Forse manca qualcosa nella documentazione. A proposito di questo: bugs.freedesktop.org/show_bug.cgi?id=82311

— vinc17

@ vinc17 è davvero interessante, appena posso ci riproverò, penso che dobbiamo trovare quel file di impostazioni e provare a imitarlo, grazie!

— Aquarius Power il

Il mio problema era dovuto al fatto che le righe KEYBOARD_KEY_ sono iniziate con 2 spazi anziché uno singolo (questo non è stato documentato e non ho ricevuto messaggi di errore!). Non lo so per te, ma con la mia tastiera USB, showkey --scancodesnon mi aspetto gli scancodes udev (i valori sono diversi); l' input-kbdutilità fornisce gli scancodes corretti.

— vinc17,

L' evtestutilità dovrebbe anche darti gli scancodes corretti: dopo aver digitato una chiave, dovresti ottenere 2 righe e la prima dovrebbe finire con qualcosa del modulo code 4 (MSC_SCAN), value xxx, dov'è xxxlo scancode. Ma il driver per la mia tastiera è difettoso e non ho questa MSC_SCANriga per alcuni tasti che volevo rimappare. Ecco perché l'ho usato input-kbd, che elenca tutti gli scancodes per il dispositivo selezionato.

— vinc17,

Ho pubblicato informazioni dettagliate in una risposta. Ora, non sono sicuro che 36 o 7002c funzionino come valore. Penso che tu abbia bisogno dell'identificatore del codice chiave. Vedi la mia risposta

— vinc17,

Per prima cosa trova lo scancode della chiave che deve essere rimappato, ad esempio con l' evtestutilità. MSC_SCANDovrebbe essere emessa una riga come la seguente (con in essa):

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

seguito da un secondo che fornisce il codice chiave corrente. Se non MSC_SCANviene emessa alcuna riga, ciò è dovuto a un bug del driver del kernel, ma lo scancode può ancora essere trovato con l' input-kbdutilità; evtestavrebbe dovuto fornire il codice chiave, in modo che sia facile trovare la riga corrispondente input-kbdnell'output (ad es. utilizzando grep).

Una volta determinati gli scancodes delle chiavi da rimappare, creare un file come /etc/udev/hwdb.d/98-custom-keyboard.hwdbcontenente i rimappature. L'inizio del file /lib/udev/hwdb.d/60-keyboard.hwdbfornisce alcune informazioni. Nel mio caso (che funziona), ho:

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

(Prima di udev 220, dovevo usare keyboard:usb:v05ACp0221*per la prima riga.)

La evdev:stringa deve essere all'inizio della riga. Si noti che le lettere nel fornitore e nell'ID prodotto devono essere in maiuscolo. Ogni KEYBOARD_KEY_impostazione deve avere esattamente uno spazio prima (nota: una riga senza spazi genererà un messaggio di errore e una riga con due spazi è stata silenziosamente ignorata con le vecchie versioni di udev). KEYBOARD_KEY_è seguito dallo scancode in esadecimale (come quello che entrambi evteste input-kbddare). Valori validi possono essere ottenuti evtestdall'output o input-kbddall'output, o anche dal /usr/include/linux/input.hfile: ad esempio, KEY_102NDdarebbe 102nd(rimuovendo KEY_e convertendo in lettere minuscole), che ho usato sopra.

Dopo aver salvato il file, digitare:

udevadm hwdb --update

per (ri) costruire il database /etc/udev/hwdb.bin(è possibile verificarne il timestamp). Poi,

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

terrà conto delle nuove impostazioni. Puoi verificare con evtest.

Nel 2014, udev rilasciato conteneva informazioni incomplete / buggy /lib/udev/hwdb.d/60-keyboard.hwdb, ma puoi guardare l'ultima versione di sviluppo del file e / o la mia segnalazione di bug e discussioni relative alla documentazione e ai problemi di spaziatura.

Se il problema persiste , il problema potrebbe essere riscontrato dopo aver temporaneamente aumentato il livello di log di udevdwith udevadm control(vedere la pagina man udevadm (8) per i dettagli).

Per le vecchie udevversioni come 204, questo metodo dovrebbe ancora funzionare.

— vinc17
fonte

Quando eseguo i comandi udevadm, il file che viene aggiornato è /lib/udev/hwdb.bin, ho guardato conbless e KEYBOARD_KEY_70085appare alla fine. Penso che Ubuntu 14.04 sia configurato (protetto?) In questo modo. Ci ho provato udevadm control --log-priority=debug. basato su lsusb(045e: 0750) la mia tastiera diventa simile keyboard:usb:v045ep0750*, ma ci ho provato keyboard:usb:v*p*anche con . Suppongo che questo /etc/udev/hwdb.bindovrebbe essere aggiornato ma non esiste nemmeno.

— Aquarius Power il

Mentre leggo qui potrebbe essere come se stessi usando questo comando udevadm hwdb --usr --update, nonostante non lo fossi.

— Aquarius Power il

Dopo udevadm hwdb --updateho copiato /lib/udev/hwdb.binper /etc/udev/hwdb.bine corse strace udevadm trigger --sysname-match="event*"e il file hwdb.binsembra non sono stati letti da esso (se è come funziona).

— Aquarius Power il

@AquariusPower Sì, potrebbe esserci un bug specifico di Ubuntu (sto usando Debian / unstable). Per vedere se il database viene letto quando lo fai udevadm trigger ..., vedi il mio test qui . Si noti che prima di eseguire udevadm trigger ..., è necessario assicurarsi che il tempo di modifica del file sia stato aggiornato, altrimenti il tempo di accesso non verrà aggiornato quando il file viene letto.

— vinc17,

@AquariusPower udevadm --version: 215 (e versione del pacchetto udev: 215-7). Grazie a udevadm trigger ..., non dovresti aver bisogno di riavviare (a meno che tu non voglia rimuovere le impostazioni, AFAIK). Ma potresti voler provare un riavvio per vedere se c'è qualche effetto.

— vinc17,