[systemd-devel] keymap: Specific models should always override more general globs

[Martin Pitt]

Hello Kay, all,

I recently debugged a keymap regression on Dells since the switch to
hwdb (https://launchpad.net/bugs/1218433). I fixed three bugs in
master already, but the remaining issue needs some discussion.

We often have rules which assign keymaps for a vendor or entire class
of models, and then have some more specific rules to change individual
keys for specific models. For example:

| keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pvr*
|  KEYBOARD_KEY_84=nextsong                               # Next song
|  KEYBOARD_KEY_9e=f21                                    # Touchpad toggle
|  [...]
| 
| keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron*1210:pvr*
|  KEYBOARD_KEY_84=wlan
| 
| keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnLatitude*:pvr*
| keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*:pvr*
|  KEYBOARD_KEY_9e=!f21

I. e. we want scan code 84 to be "nextsong" and 9e to be "F21" on
most Dells, but on the Inspiron 1210 scan code 84 means something else
("wlan") and on Latitudes and Precisions we must additionally apply
the force-release hack (that's the exclamation mark).

But that doesn't currently work. On the actual model in above bug, we
see that the assignment to _9e is from the generic (topmost) rule:

$ udevadm hwdb --test="keyboard:dmi:bvnDellInc.:bvrA02:bd11/15/2012:svnDellInc.:pnLatitude6430U:pvr01:rvnDellInc.:rn0MN74V:rvrX01:cvnDellInc.:ct9:cvr:"
KEYBOARD_KEY_9e=f21
[...]

and if we try the second rule with a made-up modalias we see the same:

$ udevadm hwdb
--test="keyboard:dmi:bvnX:bvrX:bdX:svnDellInc.:pnInspiron1210:pvrX:rvnX:rnX:rvrX:cvnX:ct9:cvr:"
KEYBOARD_KEY_84=nextsong

(We'd expect "wlan").

The actual globs are fine, if I disable the generic Dell rule these
two queries get the expected results. I suspect what happens is that
either processing stops at the first matching rule, or that all rules
are applied in some random/unpredictable order and the more specific
globs just happen to be processed before the more general "all Dell"
one, which then overwrites the previous property assignments.

Kay, is there any kind of processing order guarantee from the hwdb
trie?  This stuff worked with the old udev rules as they were
processed top down, so if one put the more generic rules first and the
specific ones below it worked. I suppose the order of hwdb.d entries
is irrelevant now, but could this e. g. sort by length of the glob, to
make shorter globs be processed first? It would be rather impractical
if the generic globs had to enumerate all Dell models which are not
Latitudes or Precisions.

Thanks,

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