Bug 82311 - /lib/udev/hwdb.d/60-keyboard.hwdb documentation issues
Summary: /lib/udev/hwdb.d/60-keyboard.hwdb documentation issues
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium minor
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-07 22:28 UTC by Vincent Lefevre
Modified: 2014-11-28 20:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Vincent Lefevre 2014-08-07 22:28:58 UTC
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.
Comment 1 Zbigniew Jedrzejewski-Szmek 2014-08-08 01:52:59 UTC
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.
Comment 2 Peter Hutterer 2014-08-08 02:57:55 UTC
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.
Comment 3 Vincent Lefevre 2014-08-08 07:56:00 UTC
(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.
Comment 4 Peter Hutterer 2014-08-10 23:33:16 UTC
I'm punting this back to the systemd folks, Zbigniew can decide if he wants to call it fixed or leave it open.
Comment 5 Vincent Lefevre 2014-08-11 01:40:52 UTC
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.
Comment 6 Vincent Lefevre 2014-11-21 15:11:14 UTC
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.
Comment 7 Peter Hutterer 2014-11-25 22:56:24 UTC
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.
Comment 8 Zbigniew Jedrzejewski-Szmek 2014-11-26 02:23:42 UTC
(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.
Comment 9 Vincent Lefevre 2014-11-26 14:01:08 UTC
(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.
Comment 10 Zbigniew Jedrzejewski-Szmek 2014-11-28 20:09:09 UTC
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.