Monday, March 14, 2016

why libinput does not have a configuration storage system

A question that pops up with some regularity is whether libinput has
a global configuration storage system, and, subsequently, why it doesn't
have one. Comparisons are drawn to the X-specific tool xinput that allows to
trigger all configuration options (see below though).

As maintainer of libinput, I can state that libinput will not get a
configuration storage system. That job is squarely in the realm of the
caller (i.e. usually the compositor and/or the desktop environment). Here are a few reasons:

First, you'd get conflicts with the caller. You need to prioritise
which configuration has precendence to decide what to do when libinput and
the caller disagree on a configuration item. You (the user) also have to
figure why a configuration doesn't work when it's clearly enabled in one
of those systems.
Ok, so you can work around this by putting in a warning somewhere, provided
that you make sure that the warning shows up in the right place and users
know where to look. And to know when to send the warning, because
again, that requires libinput to know which config has priority.

This is amplified by the lack of an autoritative support system. Speaking
from X experience, the number of posts on, say, the ubuntu forums that
advocate setting configuration options that haven't existed for years is
quite sad. Or users advocate config snippets that set everything but the
feature they claim it enables. That gets copy-pasted, etc.

Some configuration options can be incompatible with each other. If
you have conflicting configuration systems it gets harder because each
configuration system cannot make certain options an either/or anymore. We
don't have any of these options just yet, but they may come in the future.

Over time, supported features will change. A setting may be exposed in the
magic libinput config system and, a few months later, it is now also exposed
by, say, GNOME. All the documentation that points to the libinput
configuration is now obsolete because GNOME overrides it. Unless you're
running version Foo.Bar, or maybe the patched version from $DISTRIBUTION. It
gets messy quickly.

How fine-grained do you need the configuration? libinput's config API
applies separately for each device. For most desktop environments it
is sufficient to have configuration per device type (touchpad vs mouse vs
tablet, etc.). But some exceptions may apply and a newer generic touchpad configuration may need to override device-specific older configuration. Because the newer config is designed around the new libinput version, but the older config is something you copied off a forum post from 2 years ago.

Oh, implicit in the request for a configuration system in libinput is
usually also: please write and maintain that system for free, and fix any
bugs in a timely manner. And I can't shake the feeling that a large number
of these requests are only triggered by "my desktop doesn't expose this
setting, if we get it in libinput I can force it into any desktop".

Ironically enough, the tool that is usually used as an example for how it
could work is xinput. The only reason xinput works is because the
xf86-input-libinput driver exposes properties and maps changes in those to
the libinput API calls. i.e. everything is handled by libinput's caller, not
libinput itself. Just as it should be.

Lest I be accused of only shooting down ideas here is a constructive idea:
write a library or DBus-daemon that exposes some configuration storage and
makes it easy to query. Then convince the various desktop environments to
use that system instead their existing solutions, and bang, you have a
generic configuration storage system for libinput.

Sam: dconf is one possible option, but it faces the same issues: it's a GNOME-only thing (mostly, anyway), KDE uses something different and you'd have to get everyone to agree to use dconf. DBus is the closest thing to a universal system that almost everyone uses.