klawisze twarde zmiany mapowania?

Usiłuję znaleźć sposób na silne mapowanie klawiszy klawiatury.
Próbowałem użyć xmodmap i setxkbmap, ale nie działają one dla jednej konkretnej aplikacji. Takie polecenia działają dla innych normalnych okien / aplikacji na X tho.

Myślę, że aplikacja może odczytywać nieprzetworzone dane z klawiatury i ignoruje dane wejściowe X?

Jak więc mapować klucze bez użycia xmodmap i setxkbmap? jeśli kiedykolwiek można to zrobić za pomocą jakiegoś oprogramowania.

Próbowałem także xkeycaps, xkbcomp, ale nie próbowałem loadkeys, ponieważ działa na X.

Znalazłem tutaj, że mogę spróbować setkeycodes, „ponieważ po przypisaniu kodu jądra przycisk powinien działać w Xorg” , ale znalazłem również, że „nie można używać„ setkeycodes ”na klawiaturach USB” , to moja sprawa (jestem zainteresowany przypadkiem ktoś sprawi, że będzie działać na PS2, ponieważ myślę, że mógłbym użyć adaptera).

Wydawało się to obiecujące „Mapuj skancody na kody” , ale po kilku testach nic się nie zmieniło, oto one:
Znalazłem kod „36” (klawisz „j”) w vt1 z showkey
scancode „7e” (klawiatura ”.) W vt1 zshowkey --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 .: nie działa również z: KEYBOARD_KEY_7e=j

Inne alternatywne sposoby (by @ vinc17) na znalezienie kluczy:
evtest /dev/input/by-id/... lub
input-kbd 3(wstaw indeks identyfikatora znaleziony na przykład ls -l /dev/input/by-id/*z event3)

PS .: * Jeśli jesteś zainteresowany testowaniem siebie, pokrewny wątek dla aplikacji jest następujący: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ Problemy I mają takie same: niektóre klucze (KP_Decimal, DownArrow, UpArrow, RightArrow) są ignorowane i są traktowane jako wszystkie o tej samej wartości „0x00”

Najpierw znajdź kod klucza, który należy ponownie przypisać, np. Za pomocą evtestnarzędzia. MSC_SCANPowinien zostać wyświetlony wiersz podobny do następującego (z nim):

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

a następnie drugi, podając aktualny kod klucza. Jeśli nie MSC_SCANjest wyprowadzany żaden wiersz, jest to spowodowane błędem sterownika jądra, ale scancode nadal można znaleźć w input-kbdnarzędziu; evtestpowinien podać kod klucza, aby łatwo było znaleźć odpowiedni wiersz na input-kbdwyjściu (np. za pomocą grep).

Po określeniu scancodes kluczy, które mają być ponownie mapowane, utwórz plik, na przykład /etc/udev/hwdb.d/98-custom-keyboard.hwdbzawierający ponowne mapowanie. Początek pliku /lib/udev/hwdb.d/60-keyboard.hwdbzawiera pewne informacje. W moim przypadku (który działa) mam:

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

(Przed udev 220 musiałem użyć keyboard:usb:v05ACp0221*pierwszego wiersza).

evdev:Ciąg musi być na początku linii. Pamiętaj, że litery w identyfikatorze dostawcy i produktu powinny być wielkimi literami. Każde KEYBOARD_KEY_ustawienie powinno mieć wcześniej dokładnie jedną spację (uwaga: linia bez spacji wyświetli komunikat o błędzie, a linia z dwiema spacjami była cicho ignorowana w starych wersjach udev). KEYBOARD_KEY_po nim następuje scancode w systemie szesnastkowym (podobnie jak oba evtesti input-kbddają). Prawidłowe wartości można uzyskać z danych evtestwyjściowych lub input-kbdwyjściowych, a nawet z /usr/include/linux/input.hpliku: na przykład KEY_102NDdałby 102nd(przez usunięcie KEY_i konwersję na małe litery), którego użyłem powyżej.

Po zapisaniu pliku wpisz:

udevadm hwdb --update

aby (ponownie) zbudować bazę danych /etc/udev/hwdb.bin(możesz sprawdzić jej znacznik czasu). Następnie,

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

weźmie pod uwagę nowe ustawienia. Możesz to sprawdzić za pomocą evtest.

W 2014 r. Wydana wersja udev zawierała niepełne / błędne informacje /lib/udev/hwdb.d/60-keyboard.hwdb, ale możesz przejrzeć najnowszą wersję rozwojową pliku i / lub mój raport o błędach i dyskusję dotyczącą dokumentacji i problemów z odstępami.

Jeśli to nie zadziała, problem może zostać wykryty po tymczasowym zwiększeniu poziomu dziennika za udevdpomocą udevadm control(szczegóły na stronie podręcznika udevadm (8)).

W przypadku starszych udevwersji, takich jak 204, ta metoda powinna nadal działać.