17

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"

  • 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 Nov 21 '14 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! – Aquarius Power Nov 22 '14 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 Nov 26 '14 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 Nov 26 '14 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 Nov 28 '14 at 0:33
14

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:

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

(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, and 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. – Aquarius Power Nov 29 '14 at 23:06
  • As I read here it could be like I was using this command udevadm hwdb --usr --update, despite I was not. – Aquarius Power Nov 29 '14 at 23:07
  • After udevadm hwdb --update I copied /lib/udev/hwdb.bin to /etc/udev/hwdb.bin and ran strace udevadm trigger --sysname-match="event*" and the file hwdb.bin seems have not been read by it (if it is like this works). – Aquarius Power Nov 29 '14 at 23:16
  • 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 Nov 29 '14 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 Nov 29 '14 at 23:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.