I am trying to find a way to remap keyboard keys forcefully.
I tried using xmodmap and setxkbmap, but they do not work for one specific application. Such commands work for other normal windowed/applications on X tho.
I think the application may be reading the keyboard raw data and ignoring X input?
So, how to remap keys without using xmodmap and setxkbmap? if it is ever possible to be done using some software.
I also tried xkeycaps, xkbcomp, but did not try loadkeys, as it is running on X.
I found here that I could try setkeycodes
, "because after assigning kernel keycode the button should work in xorg", but I also found that "you can't use 'setkeycodes' on USB keyboards", that's my case (I am interested in case someone make it work on ps2 as I think I could use an adapter).
This seemed promising "Map scancodes to keycodes", but after a few tests nothing changed, here are they:
I found keycode "36" ("j" key) at vt1 with showkey
I found scancode "7e" (keypad ".") at vt1 with showkey --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.: did not work either with: KEYBOARD_KEY_7e=j
Some more alternative ways (by @vinc17) to find the keys:
evtest /dev/input/by-id/...
or
input-kbd 3
(put the id index found at ls -l /dev/input/by-id/*
from ex. event3)
PS.: *If you are interested on testing yourself, the related thread for the application is this: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ The issues I have are the same: some keys (KP_Decimal, DownArrow, UpArrow, RightArrow) are ignored and considered all with the same value there "0x00"
Best Answer
First find the scancode of the key that needs to be remapped, e.g. with the
evtest
utility. A line like the following one (withMSC_SCAN
in it) should be output:followed by a second one giving the current key code. If no
MSC_SCAN
line is output, this is due to a kernel driver bug, but the scancode can still be found with theinput-kbd
utility;evtest
should have given the key code, so that it should be easy to find the corresponding line in theinput-kbd
output (e.g. by usinggrep
).Once the scancodes of the keys to be remapped have been determined, create a file such as
/etc/udev/hwdb.d/98-custom-keyboard.hwdb
containing the remappings. The beginning of the file/lib/udev/hwdb.d/60-keyboard.hwdb
gives some information. In my case (which works), I have:(Before udev 220, I had to use
keyboard:usb:v05ACp0221*
for the first line.)The
evdev:
string must be at the beginning of the line. Note that the letters in the vendor and product id should be capital letters. EachKEYBOARD_KEY_
settings should have exactly one space before (note: a line with no spaces will give an error message, and a line with two spaces were silently ignored with old udev versions).KEYBOARD_KEY_
is followed by the scancode in hexadecimal (like what bothevtest
andinput-kbd
give). Valid values could be obtained from either theevtest
output or theinput-kbd
output, or even from the/usr/include/linux/input.h
file: for instance,KEY_102ND
would give102nd
(by removingKEY_
and converting to lower case), which I used above.After the file is saved, type:
to (re)build the database
/etc/udev/hwdb.bin
(you can check its timestamp). Then,will take the new settings into account. You can check with
evtest
.In 2014, the released udev had incomplete/buggy information in
/lib/udev/hwdb.d/60-keyboard.hwdb
, but you can look at the latest development version of the file and/or my bug report and discussion concerning the documentation and spacing issues.If this doesn't work, the problem might be found after temporarily increasing the log level of
udevd
withudevadm control
(see the udevadm(8) man page for details).For old
udev
versions such as 204, this method should still work.