Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Mon, Mar 02, 2015 at 03:03:06PM +0100, drago01 wrote:
> On Mon, Mar 2, 2015 at 1:32 AM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Thu, Feb 26, 2015 at 09:49:48AM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 24-02-15 18:34, drago01 wrote:
> >> >On Mon, Feb 23, 2015 at 1:32 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> >> >>Hi All,
> >> >>
> >> >>As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
> >> >>
> >> >>We've been working on making xorg-x11-drv-libinput the default input driver
> >> >>for the Xorg xserver under Fedora 22. All the necessary changes for this are
> >> >>in place for the GNOME and KDE desktops. So starting with the next Fedora 22
> >> >>compose new Fedora 22 Workstation installations will be using
> >> >>xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.
> >> >>
> >> >>For existing installations the move to libinput will not happen
> >> >>automatically, as  we have not added a hard dependency on
> >> >>xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old
> >> >>drivers until they have adopted their mouse/touchpad configuration settings
> >> >>tools to also work with xorg-x11-drv-libinput.
> >> >>
> >> >>If you're running F-22 with GNOME or KDE, please do the following to switch
> >> >>to the new driver:
> >> >>
> >> >>"sudo dnf install xorg-x11-drv-libinput"
> >> >>
> >> >>And let us know if you experience any issues while using the new driver.
> >> >
> >> >So we'd have two sets of users ... those who upgraded and those how
> >> >reinstalled running different drivers for the same hardware?
> >>
> >> Yes, we need to maintain both stacks for a while anyways for e.g. lxde users,
> >> etc. Given that XFCE now supports libinput too, we could reconsider this
> >> and make xorg-drv-libinput a hard dep of the X server so that everyone gets
> >> it, but officially we are past the end of the feature merge window.
> >>
> >> Peter, any thoughts on this ?
> >
> > not this cycle, IMO. there are some behaviour changes between
> > evdev/synaptics and libinput. That's fine for a new install, but changing
> > that on update can be considered a regression for some. At least
> > for F22 I think we should leave things as is.
> 
> Well going by the workstation PRD:
> 
> "Upgrading the system multiple times through the upgrade process
> should give *a result that is the same as an original install of
> Fedora Workstation*. [...] "
> (https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Overall_plans_and_policies_for_the_product)
> 
> if it is good enough for new installs it is good enough for upgrades.

this is where it gets a bit complicated. evdev and synaptics are the current
default drivers. xlibinput is the new default. 
["xlibinput" here meaning xorg-x11-drv-libinput, I'm lazy today]

"default" means two things: what we install and what the server will pick
for each specific device. the latter is decided by xorg.conf.d snippets that
we ship with the drivers. xlibinput simply sorts later than evdev/synaptics
and can thus override the selections of others.

to switch to xlibinput on upgrade we have to somehow force the xlibinput
driver onto their systems. Can be done with a Provides/Obsoletes but the
xlibinput driver is simply not the same as evdev/synaptics so that's
questionable to begin with.

Besides, this can seriously break local configuration, if you have an
/etc/X11/xorg.conf.d snippet that assigns the evdev driver this will
override the distro-shipped xlibinput assignment. if we remove the
evdev/synaptics drivers on upgrade this will leave the user with no input
devices.

I don't have a good solution to this, tbh, at least nothing short of
trawling the system for xorg.conf.d snippets and guessing what will
eventually apply on server start. and that's not a good idea, for all the
obvious reasons.

The upstream long-term solution is likely to merge xlibinput into the server
so we always have a fallback driver. Then if evdev isn't there we can still
fall back onto libinput. We're not there yet though and likely won't be for
the next cycle.

Cheers,
   Peter