Adding xorg-x11-drv-libinput to the Desktop's set of default packages

Peter Hutterer peter.hutterer at
Mon Jan 12 23:48:57 UTC 2015

On Mon, Jan 12, 2015 at 04:12:01PM +0100, Hans de Goede wrote:
> >>Running KDE apps on top of the GNOME desktop will not be affected,
> >>actually even with xorg-x11-drv-libinput installed KDE itself will
> >>still work fine, the only thing which will not work is KDE's configuration
> >>applet for configuring touchpad settings like tap-to-click.
> >>
> >>If KDE users have xorg-x11-drv-libinput installed (somehow) and they
> >>want something else then the default touchpad behaviour they can still
> >>get it but the will need to use xinput from the commandline to change
> >>the settings; or they can simply do "rpm -e xorg-x11-drv-libinput",
> >>restart X and have everything as it was in F-21, even if they started
> >>with the desktop product.
> >>
> >>We are planning a gradual transition here, where both the old and new
> >>xorg drivers will be supported, independent of the DE really, but we
> >>would like to slowly move towards the new driver, so for F-22 the plan
> >>is to have GNOME's input configuration bits know how to talk to either
> >>driver, and have the new driver installed by default on the desktop
> >>product.
> >
> >Can't we just make whatever the package that contains the KDE control
> >panel to carry a /etc/X11/xorg.conf.d/ snippet that enables the
> >synaptics driver?
> >That way you get libinput by default and synaptics if you install KDE
> >... as GNOME handles both it won't break GNOME.
> >
> >In F23 once KDE is ported we can stop shipping that file.
> Hmm, interesting suggestion, I've been unable to find clear documentation
> on the ordering of parsing xorg.conf.d snippets in general, and the
> ordering of parsing stuff under /usr/share/X11 vs under /etc .
> Peter, can you shed some light on the parsing ordering (we should really
> add something about this to "man xorg.conf".
> Peter, what do you think about Draco's suggestion ?

The lookup order is (in lowest priority first):

with the directories being read in sorted order (but /etc always overrides
/usr). we only ship snippets in /usr/share and leave /etc up to the user, so
that's what KDE would have to do as well.

There are two drawbacks to this approach:
First, we can't remove synaptics/evdev because many people have a
copy-pasted InputClass snippet that includes the Driver "synaptics" or
"evdev" line.  That'll override any system config so if we don't have the
drivers installed those users get dead devices. Fixable in the server by
setting libinput if the module isn't present but that needs to be done
upstream first.

Second, config files can only add up and override, not remove options. But
we can match on already-assigned driver, so this should work:
Section "InputClass"
   Identifier "restore synaptics"
   MatchDriver "libinput"
   MatchIsTouchpad "on"
   Driver "synaptics"

that then needs to have a higher sort-order than whatever assigns libinput.

I think that's the sanest plan. It's still nasty because _installing_ a
package will change your config rather than running it. But the only way out
of that would be to have the DM write out a config on-the-fly if a KDE is
started. Doable, but more room for error and given it's meant to be
temporary not worth the effort.


More information about the desktop mailing list