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

Hans de Goede hdegoede at
Tue Jan 13 09:21:52 UTC 2015


On 13-01-15 00:48, Peter Hutterer wrote:
> 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):
> /usr/share/X11/xorg.conf.d
> /etc/X11/xorg.conf.d/
> /etc/X11/xorg.conf
> 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"
> EndSection

Ah yes, that should work, and kcm_touchpad could install that with a high
priority. That might be a good solution, I say might because I'm not 100% sold
on this, this means that a user installing KDE once, just to give it a try,
will then be moved back to synaptics and things will stay that way.

It may be better to just tell people to do "rpm -e xorg-x11-drv-libinput" if
they started with the Workstation product and want to use kcm_touchpad, AFAIK
kcm_touchpad will register itself with the KDE control-panel if the synaptics
driver is loaded, so if we end up using libinput kcm_touchpad will simple not
show, rather then break.

So opinions on this anyone ?

Note ideally someone would step up to make kcm_touchpad work with libinput,
that likely needs to happen eventually anyways, see e.g. also :

> 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