This is a copy of my bug report in the Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757367 (for systemd/208-7). /lib/udev/hwdb.d/60-keyboard.hwdb contains some documentation at the beginning, but there are several problems with it. First, a typo: charcter -> character It says: # Scan codes are specified as: # KEYBOARD_KEY_<hex scan code>=<key code identifier> # The scan code should be expressed in hex lowercase and in # full bytes, a multiple of 2 digits. The key codes are retrieved ^^^^^^^^^^^^^^^^^^^^^^ # and normalized from the kernel input API header. but in the settings, scan codes are also expressed on 3 or 5 digits, e.g. # enhanced USB keyboard keyboard:usb:v04B3p301B* KEYBOARD_KEY_90001=prog1 # ThinkVantage KEYBOARD_KEY_90002=screenlock KEYBOARD_KEY_90003=file KEYBOARD_KEY_90004=wordprocessor KEYBOARD_KEY_90005=spreadsheet KEYBOARD_KEY_90006=calc KEYBOARD_KEY_90007=mail KEYBOARD_KEY_90008=www # Satellite U940 keyboard:name:Toshiba*input*device:dmi:bvn*:bvr*:bd*:svnTOSHIBA*:pnSATELLITEU940:pvr* KEYBOARD_KEY_13c=brightnessdown KEYBOARD_KEY_13d=brightnessup KEYBOARD_KEY_13e=switchvideomode KEYBOARD_KEY_13f=f21 # Touchpad toggle Thus this is confusing. It also says: # To debug key presses and access scan code mapping data of # an input device use the commonly available tool: evtest(1). Unfortunately, evtest doesn't output scan codes for some keys: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757356 The udev keymap utility had the same problem, but once patched, it could output the full keymap as a workaround. Unfortunately, evtest cannot do that (well, I didn't see anything like that in its documentation). The input-kbd utility can do that, so that it would be a good idea to mention it too. Moreover this file should also say how one can do some tests and where one can look for error messages. And what should be done to take the changes into account? After a search on the web, it seems that most users don't know either. http://marcin.juszkiewicz.com.pl/2014/03/03/how-to-get-zoom-slider-on-microsoft-keyboard-recognized-by-x11/ says: udevadm hwdb --update udevadm control --reload but one needs to replug the keyboard (or reboot!). http://askubuntu.com/questions/499252/my-custom-udev-hwdb-rule-doesnt-work just says: udevadm hwdb --update but it doesn't work. http://forums.fedoraforum.org/showpost.php?p=1681790&postcount=3 says: udevadm hwdb --update udevadm trigger udevadm control --reload which might be the solution.
Description updated in http://cgit.freedesktop.org/systemd/systemd/commit/?id=fa9d4be3f1. I'll reassign this bug to evtest, let's see what they say.
There isn't much I can do here in evtest, we just blindly print whatever the kernel gives us. If we don't get anything from the kernel, we don't have anything to print.
(In reply to comment #2) > There isn't much I can do here in evtest, we just blindly print whatever the > kernel gives us. If we don't get anything from the kernel, we don't have > anything to print. Then this would be a kernel bug. In such a case, the only solution for the user is to output the entire keymap (not possible with evtest) and see which scan code corresponds to the obtained key.
I'm punting this back to the systemd folks, Zbigniew can decide if he wants to call it fixed or leave it open.
Even when there are no kernel bugs, input-kbd may still be useful under some occasions: * when the physical keyboard is remote; * when the user is interested in the complete map instead of testing keys one by one.
A part of http://cgit.freedesktop.org/systemd/systemd/commit/?id=fa9d4be3f1 ("simply use /dev/input/event* to reload all input rules") is incorrect: xvii:/home/vinc17# udevadm hwdb --update xvii:/home/vinc17# ls -lu /etc/udev/hwdb.bin -r--r--r-- 1 root root 6559371 2014-11-21 16:05:27 /etc/udev/hwdb.bin xvii:/home/vinc17# udevadm trigger /dev/input/event* Extraneous argument: '/dev/input/event0' xvii:/home/vinc17# ls -lu /etc/udev/hwdb.bin -r--r--r-- 1 root root 6559371 2014-11-21 16:05:27 /etc/udev/hwdb.bin xvii:/home/vinc17# udevadm trigger xvii:/home/vinc17# ls -lu /etc/udev/hwdb.bin -r--r--r-- 1 root root 6559371 2014-11-21 16:05:51 /etc/udev/hwdb.bin As you can see, /etc/udev/hwdb.bin isn't read with: udevadm trigger /dev/input/event* However, even after "udevadm trigger" nothing changed in the keyboard mapping. Nothing changed after a reboot either. So, I'm wondering. I've checked that the generated /etc/udev/hwdb.bin file contains parts of strings from my remappings, which are: keyboard:usb:v05ACp0221* KEYBOARD_KEY_29=102nd KEYBOARD_KEY_56=grave KEYBOARD_KEY_1d0=insert I don't seem to be the only one noticing no changes via hwdb remappings. See for instance: http://unix.stackexchange.com/questions/156985/keyboard-hard-remap-keys Either there is a bug in udev, or something else is missing in the documentation. BTW, it would be nice to have information for debugging.
try udevadm trigger --sysname-match="event*" also, make sure you run all this as root. also, if you use the --verbose flag you see what devices it applies to, if the list is empty then it doesn't match on anything. If it prints out a number of paths but nothing changes, the problem is elsewhere.
(In reply to Vincent Lefevre from comment #6) > As you can see, /etc/udev/hwdb.bin isn't read with: > > udevadm trigger /dev/input/event* Argh, fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=80877656a5. > However, even after "udevadm trigger" nothing changed in the keyboard > mapping. Nothing changed after a reboot either. So, I'm wondering. > > I've checked that the generated /etc/udev/hwdb.bin file contains parts of > strings from my remappings, which are: > > keyboard:usb:v05ACp0221* > KEYBOARD_KEY_29=102nd > KEYBOARD_KEY_56=grave > KEYBOARD_KEY_1d0=insert I think you have double spaces here, which doesn't work. Incidentally, Peter said he might write a patch to ignore leading whitespace, which would also fix the problem.
(In reply to Zbigniew Jedrzejewski-Szmek from comment #8) > (In reply to Vincent Lefevre from comment #6) > > keyboard:usb:v05ACp0221* > > KEYBOARD_KEY_29=102nd > > KEYBOARD_KEY_56=grave > > KEYBOARD_KEY_1d0=insert > I think you have double spaces here, which doesn't work. Incidentally, > Peter said he might write a patch to ignore leading whitespace, which > would also fix the problem. Indeed tests show that one must have only one space. But this wasn't documented, and there were no errors from udevadm! So, now, with the correct scan codes (which I had tried in the first place but didn't work because of the double space, hence the confusion): keyboard:usb:v05ACp0221* KEYBOARD_KEY_70035=102nd KEYBOARD_KEY_70064=grave KEYBOARD_KEY_70068=insert works fine.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=36afca67b6 makes duplicate leading whitespace ignored.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.