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
$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
$#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"

  • The updated file should be /etc/udev/hwdb.bin, not /lib/udev/hwdb.bin. But though this file is updated correctly, this doesn't work for me either, even after a reboot. Perhaps something missing in the documentation. About this: bugs.freedesktop.org/show_bug.cgi?id=82311
    – vinc17
    Commented Nov 21, 2014 at 16:02
  • @vinc17 that is really interesting, as soon I can I will try again, I think we have to find that settings file and try to imitate it, thx! Commented Nov 22, 2014 at 16:28
  • 1
    My problem was due to the fact that the KEYBOARD_KEY_ lines started with 2 spaces instead of a single one (this wasn't documented and I got no error messages!). I don't know for you, but with my USB keyboard, showkey --scancodes doesn't give the scancodes udev expects (the values are different); the input-kbd utility gives the correct scancodes.
    – vinc17
    Commented Nov 26, 2014 at 14:17
  • 1
    The evtest utility should also give you the correct scancodes: after typing a key, you should get 2 lines and the first one should end with something of the form code 4 (MSC_SCAN), value xxx, where xxx is the scancode. But the driver for my keyboard is buggy, and I don't get this MSC_SCAN line for some keys I wanted to remap. That's why I used input-kbd, which lists all the scancodes for the selected device.
    – vinc17
    Commented Nov 26, 2014 at 14:28
  • 1
    I've posted detailed info in an answer. Now, I'm not sure that 36 or 7002c works as a value. I think that you need the key code identifier. See my answer.
    – vinc17
    Commented Nov 28, 2014 at 0:33

1 Answer 1


First find the scancode of the key that needs to be remapped, e.g. with the evtest utility. A line like the following one (with MSC_SCAN in it) should be output:

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

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 the input-kbd utility; evtest should have given the key code, so that it should be easy to find the corresponding line in the input-kbd output (e.g. by using grep).

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:

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

(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. Each KEYBOARD_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 both evtest and input-kbd give). Valid values could be obtained from either the evtest output or the input-kbd output, or even from the /usr/include/linux/input.h file: for instance, KEY_102ND would give 102nd (by removing KEY_ and converting to lower case), which I used above.

After the file is saved, type:

udevadm hwdb --update

to (re)build the database /etc/udev/hwdb.bin (you can check its timestamp). Then,

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

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 with udevadm control (see the udevadm(8) man page for details).

For old udev versions such as 204, this method should still work.

  • When I run the udevadm commands, the file that gets updated is /lib/udev/hwdb.bin, I looked with bless and the KEYBOARD_KEY_70085 appears at its end. I think ubuntu 14.04 is configured (protected?) this way. I tried udevadm control --log-priority=debug. based on lsusb (045e:0750) my keyboard gets like keyboard:usb:v045ep0750*, but I tried with keyboard:usb:v*p* too. My guess is this /etc/udev/hwdb.bin should be updated but doesnt even exist. Commented Nov 29, 2014 at 23:06
  • As I read here it could be like I was using this command udevadm hwdb --usr --update, despite I was not. Commented Nov 29, 2014 at 23:07
  • 1
    @AquariusPower Yes, there may be an Ubuntu specific bug (I'm using Debian/unstable). To see whether the database is read when doing udevadm trigger ..., see my test here. Note that before running udevadm trigger ..., you need to make sure that the modification time of the file has been updated, otherwise the access time will not be updated when the file is read.
    – vinc17
    Commented Nov 29, 2014 at 23:23
  • 1
    @AquariusPower udevadm --version: 215 (and udev package version: 215-7). Thanks to udevadm trigger ..., you shouldn't need to reboot (unless you want to remove settings, AFAIK). But you may want to try a reboot to see if there is any effect.
    – vinc17
    Commented Nov 29, 2014 at 23:44
  • 2
    For the evdev:input:bZZZZvYYYYpXXXX, ZZZZ, YYYY and XXXX and are the 4-digit hex uppercase bus, vendor and product ID (they are explained in /lib/udev/hwdb.d/60-keyboard.hwdb). To obtain these values of your keyboard, first use evtest to identify the event number eventX of it, then check files under /sys/class/input/eventX/device/id/.
    – zsrkmyn
    Commented Dec 6, 2019 at 5:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .