[PATCH libinput 00/10] libinput device quirks config files

[Peter Hutterer]

On Mon, May 28, 2018 at 12:54:57PM +0300, Pekka Paalanen wrote:
> On Mon, 28 May 2018 18:08:26 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > This is the first implementation of the .ini style config files for
> > libinput's device quirks. I first described this here:
> > https://lists.freedesktop.org/archives/wayland-devel/2018-May/038233.html
> > 
> > This is NOT a configuration API.  This is a replacement for the hwdb entries
> > we currently ship. It sets quirks that devices need like "this tablet
> > has a known broken event stream" that we then handle in custom code paths.
> > It doesn't do any configuration items exposed through the
> > libinput_device_config_* API.
> > 
> > It's not libinput API and it's not really user-visible in
> > that you shouldn't need those files except if you're the first one to spot
> > an issue that needs a quirk.
> > 
> > The basic approach is simple - a bunch of files in
> > /usr/share/libinput/*.quirks with entries like this:
> > 
> > [Aiptek No Tilt Tablet]
> > MatchUdevType=tablet
> > MatchBus=usb
> > MatchVendor=0x08CA
> > ModelTabletNoTilt=1
> > 
> > For comparsion, the hwdb entry for this one is currently:
> > libinput:tablet:input:b0003v08CAp*
> >  LIBINPUT_MODEL_TABLET_NO_TILT=1
> > 
> > There is some accommodation for custom local overrides, a
> > single file defaulting to /etc/libinput/local-overrides.quirks
> > Since this isn't public API and any changes should be upstreamed, a single
> > file for local overrides is enough.
> 
> Hi Peter,
> 
> it all sounds fine to me, but it's not really my expertise.
> 
> Did you think whether it would be too obnoxious to have a libinput
> version tag in local-overrides.quirks and reject the file if it doesn't
> match the running libinput version? That would annoy people who carry
> local quirks every time libinput updates, hopefully poking them towards
> upstreaming their changes rather than only fixing the version tag.

tbh, I think that's more effort than it's worth. I'd have to bump the
version on the libinput side before releases (and some incompatible changes
may feed into the stable branch, so suddenly we'd have multiple different
versions to take care of). Also, anything versioned also (somewhat)
suggests that there is stability if the version stays the same. That is not
really the case if you're e.g. feeding off git master.

As it is now, a parsing error due to a now-unknown option will simply
deactivate all the quirks, you get a nice error message and a link to the
documentation (not yet written :)

Cheers,
   Peter