[udev] changing hwdb requires calling udevadm control --reload

[Malte Wetz]

I have a small gaming keyboard (Ideozon Fang) which has a terrible default keymapping that I want to fix. To do that, I need to change its default keymapping. But only for that keyboard and no other. My system is Ubuntu 14.04 (amd64).

As an example, I will change the key '3' which is by default mapped to 'Numpad 3' to 'PgDn'.

The old way that used to work (and still does in Debian 7.6) was this:

<----- snip ----->
root@debian~# /lib/udev/keymap -i /dev/input/event7
Press ESC to finish, or Control-C if this device is not your primary keyboard
scan code: 0x7005B key code: kp3

root@debian~# cat /etc/udev/keymaps/ideazon-zboard
0x7005B pagedown

root@debian~# /lib/udev/keymap /dev/input/event7 /etc/udev/keymaps/ideazon-zboard
Remapped scancode 0x7005b to 0x6d (prior: 0x51)

root@debian~# evtest /dev/input/event7
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1038 product 0x310 version 0x111
Input device name: "Ideazon Zboard USB Gaming Device"
[...]
Event: time 1408993871.777960, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7005b
Event: time 1408993871.777971, type 1 (EV_KEY), code 109 (KEY_PAGEDOWN), value 1
<----- snap ----->

However, this method does not work anymore in 14.04 (for instance, there is no 'keymap' utility). Now, if I researched it correctly, we are supposed to do this:

<----- snip ----->
root@ubuntu:~# lsusb | grep -i ideazon
Bus 003 Device 009: ID 1038:0310 Ideazon, Inc.

root@ubuntu:~# cat /etc/udev/hwdb.d/91-local-ideazon-zboard.hwdb
keyboard:usb:v1038p0310*
 KEYBOARD_KEY_07005b=pagedown

root@ubuntu:~# udevadm hwdb --update

root@ubuntu:~# evtest /dev/input/event6
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1038 product 0x310 version 0x111
Input device name: "Ideazon Zboard USB Gaming Device"
[...]
Event: time 1408993986.205654, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7005b
Event: time 1408993986.205654, type 1 (EV_KEY), code 81 (KEY_KP3), value 1
<----- snap ----->

But, as you can see, it does not work. 'evtest' still reports the key as 'Numpad 3'. Even unplugging and re-plugging the keyboard has no effect. 'udevadm' seems to compile my custom file alright (it complains if I purposefully put a syntax error in it). But I still cannot redefine my keymap.

I do not know if this is a problem of the newer udev itself. But even if it is, Ubuntu should not use it until it actually works. Especially not in a LTS version.

[Malte Wetz (mjw-de)]

I figured out what the problem was myself: The manpage of udevadm is incorrect. Or at least misleading. It says:

<----- snip ----->
   udevadm hwdb [options]
       Maintain the hardware database index in /lib/udev/hwdb.bin.

       --update
           Compile the hardware database information located in
           /lib/udev/hwdb.d/, /etc/udev/hwdb.d/ and store it in
           /lib/udev/hwdb.bin. This should be done after any update to the
           source files; it will not be called automatically. The running udev
           daemon will detect a new database on its own and does not need to
           be notified about it.
<----- snap ----->

The last sentence seems to indicate that compiling the hwdb is the only thing you have to do to make changes take effect. This, however, is NOT true on my system.

Not only did I have to recompile the hwdb but you also reload it: 'udevadm control --reload'.

Then I had to re-connect the keyboard in question.

And *then* I could use the new keymapping.

I therefore suggest to change the sentence in the manpage above to say the exact opposite, refer the user to the 'udevadm control --reload' command and tell them to reconnect the hardware (or reboot, if hotplugging is not supported).

[Martin Pitt (pitti)]

Malte Wetz [2014-08-26 9:56 -0000]:
> The last sentence seems to indicate that compiling the hwdb is the only
> thing you have to do to make changes take effect.

Yes, that's indeed the intended mode. It works like that just fine
here. Of course you have to either unplug/replug the keyboard, or send
an udevadm trigger to make udev actually apply it to an existing
keyboard.

> Not only did I have to recompile the hwdb but you also reload it:
> 'udevadm control --reload'.

That's not supposed to be necessary. What kind of machine and file
system do you use? Anything which might not support inotify, such as
overlayfs, etc.?

[Malte Wetz (mjw-de)]

Well, firstly 'udevadm trigger' also does not work. I really have to physically reconnect or unbind and rebind via sysfs to get the mapping working. Just for the record.

As for your other question: It's a relatively normal system
- Intel Core i5-4570 (Haswell)
- 8 GB RAM
- Asrock H87 Pro4 (Intel H87 chipset)
- Kubuntu 14.04 (currently running kernel 3.13.0-34-generic)
- System is installed on a Crucial M500 SSD
- My rootfs is a simple ext4 (no overlays that I'm aware of), /boot is an ext2 and /home an ext4 on another (larger) hard disk
- I boot in the old BIOS mode and do *not* use UEFI boot

I also tried it with Xubuntu 14.04 in a VirtualBox system with the USB device passed through. Same effect. The keyboard in question is usually connected to a 10-Port USB-Hub from Logilink. But if I connect it directly to the USB port at the mainboard's back side or even an additional Renesas USB3 controller card, nothing changes.

I do not see any new entries in the syslog after the 'udevadm hwdb --update' command. Not sure if I'm supposed to, though.

During my research, I found some links where other people seem to have similar problems:
http://askubuntu.com/questions/471802/where-has-lib-udev-keymap-gone-how-do-i-adjust-keymaps-in-trusty
http://marcin.juszkiewicz.com.pl/2014/03/03/how-to-get-zoom-slider-on-microsoft-keyboard-recognized-by-x11/
http://forums.fedoraforum.org/showpost.php?p=1681790&postcount=3

[Martin Pitt (pitti)]

To confirm, do you actually need the "udevadm control --reload", or is unplugging/replugging the keyboard enough after changing the keymaps?

[Malte Wetz (mjw-de)]

All of these steps are necessary:

- udevadm hwdb --update
- udevadm control --reload
- replug the keyboard or do a unbind-bind-cycle via sysfs

Not doing any one of them will not produce the intended effect.