[RFC] libinput device quirks config files

[Peter Hutterer]

libinput needs a bunch of device-specific quirks to function correctly.
These quirks are divided into two categories - model-specific flags ("this
is an apple touchpad") and attributes we cannot get from the kernel (e.g.
sizes, pressure thresholds, etc.).

Note: this is *not* about libinput configuration, this is about
device-specific quirks.

Right now, libinput uses the systemd hwdb to match on a device and apply the
quirk.  Two advantages: we don't have to worry about storage format, reading
a property is simple. And second, the quirks can be updated without having
to recompile libinput [1].

but I'm starting to hit the limits with the hwdb.  First, it's easy to
update if you know what you're doing but debugging when it doesn't work is a
pain.  Even checking whether it applied at all is something a lot of
reporters raise the white flag in surrender.

Second, it's hard to automatically generate a hwdb entry that will
definitely match and is sensible.

Third, the hwdb matching is basically defined by the implementation. There
are file sort orders, but overriding a previous match is not as reliable as
you'd expect. For example, consider these two rules:

evdev:name:Synaptics TM2668-002:dmi:*svnLENOVO*:pvrThinkPadT440s:*
  FOO=1
evdev:name:Synaptics TM2668-002:dmi:*:svnLENOVO*:pvrThinkPadT440s:*
  FOO=2

The output of this is *always* FOO=1, regardless of the filename the hwdb
match is in.

This has bitten me a few times on an irregular basis, although admittedly
always in experimental features  that didn't end up on git master in the
end. Also note that for the hwdb to work, the udev rule to compile that hwdb
match has to be in place too, though that's not usually an issue.

What I'm planning is to replace the hwdb matches with a libinput-specific
set of config files in the .ini format. So we'd have a bunch of files with
content in this form:

    [Synaptics touchpad]
    MatchBus=usb
    MatchName=*Synaptics Touchpad*
    AttrSizeHint=50x50
    ModelSynapticsTouchpad=1

    [Apple touchpad]
    MatchVendor=0x5AC
    MatchProduct=0x123
    ModelAppleTouchpad=1


The advantages are mainly better human readability and the ability to write
our own debug tools to analyse why a device matches or doesn't.
Disadvantage is that libinput has to open and parse a bunch of files during
init. But since these are part of libinput, we don't need to jump through
open_restricted(), if libinput cannot read files in its own data directory,
something is wrong. Some accommodation has to be made for temporary
overrides in /etc/ but the same rules apply here.

Implementation-wise it's relatively simple, especially since these files
will not be part of the API (i.e. we can change them at any time). Just
reading files line-by-line is sufficient here and doing the absolute minimum
to ensure it's a valid .ini file. There are a few details that I still need
to sort out (local overrides, test suites, etc.) but the basics are
straightforward.

Any thoughts? This is libinput-internal implementation and has no visible
effect on the callers.

Cheers,
   Peter


[1] this is only true if libinput already supports a flag/attr already and
we're just adding it to another device or changing its value. maybe about
half the time overall.