Replacement for hal-setup-keymap

[Martin Pitt]

Hello Kay,

Kay Sievers [2009-05-05 13:48 +0200]:
> "[dmi/id]:<attribute-name>" should work to get to that information.

That's it, thanks!

> I think Lennart had some tool too, that may be useful, if I remember correctly.

We discussed keyfuzz in #udev today. However, most of it is not
necessary any more, and I noticed that the core bit (poking a list of
keycode assignments into an evdev device) is already provided by the
"input-kbd" program in the input-utils package. It exists in
Debian/Ubuntu and seeminly in SUSE, but apparently not in Fedora. It's
a pretty trivial tool, so if necessary we can just adapt Lennart's
keyfuzz accordingly.

I now wrote a small hackish script (current version: [1]) which
convers a set of keymap fdi files into udev rules:

| $ ./fdi2rules.py /usr/share/hal/fdi/information/10freedesktop/30-keymap-{dell*,hp*} > 95-keymap.rules
| $ cat 95-keymap.rules 
| ACTION!="add", GOTO="keyboard_end"
| SUBSYSTEM!="input", GOTO="keyboard_end"
| DRIVERS=="atkbd", GOTO="keyboard_vendorcheck"
| GOTO="keyboard_end"
| 
| LABEL="keyboard_vendorcheck"
| ATTR{[dmi/id]sys_vendor}=="Dell*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/dell' %n"
| ATTR{[dmi/id]sys_vendor}=="Dell*", ATTR{[dmi/id]product_name}=="*Latitude XT*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/dell-latitude_xt' %n"
| ATTR{[dmi/id]sys_vendor}=="Hewlett-Packard*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/hewlett-packard' %n"
| ATTR{[dmi/id]sys_vendor}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*Tablet*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/hewlett-packard-tablet' %n"
| ATTR{[dmi/id]sys_vendor}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*Pavilion*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/hewlett-packard-pavilion' %n"
| ATTR{[dmi/id]sys_vendor}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*Compaq*|*EliteBook*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/hewlett-packard-compaq_elitebook' %n"
| ATTR{[dmi/id]sys_vendor}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*2510p*|*2530p*", RUN+="/usr/bin/input-kbd -f '/usr/share/keymaps/hewlett-packard-2510p_2530p' %n"
| 
| LABEL="keyboard_end"

The generated data files [2] look like

| $ head -n 3 /usr/share/keymaps/dell
| 0x81 = KEY_PLAYPAUSE
| 0x82 = KEY_STOPCD
| 0x83 = KEY_PREVIOUSSONG

Originally I intended this to become a script which we can run
permanently to maintain keymaps in hal-info side by side with the new
udev-extras rules. However, udev rules are not expressive enough for
some of the weirder constructs we currently have in the hal-info
keymaps, and converting other constructs in the script would take more
development time than to just handle them manually.

So, my questions:

 - Does the general structure of the approach and rules look okay?

 - Would you prefer using input-utils or a copy of the input-kbd
   script in udev-extras?

 - Is everyone okay with doing this as an one-time migration? If so,
   I'll create the lists from our current hal-info data with
   fdi2rules.py and some manual cleanup.

 - Do you think that in the future these udev rules should be
   maintained as they are, or being autogenerated from a more abstract
   source format which avoids the udev boilerplate?

Thanks for any comment,

Martin

[1] http://people.ubuntu.com/~pitti/tmp/fdi2rules.py
[2] http://people.ubuntu.com/~pitti/tmp/data/

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)