synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Raphael Hertzog]

[ Bcc debian-x and debian-gtk-gnome, discussion on -devel as the topic
crosses the boundaries of multiple teams ]

Hello,

it has been some time that GNOME 3.20 users have been unable to configure
their touchpad[1] because:
1/ xserver-xorg-input-synaptics cherry-picked an upstream commit[2]
that gives the priority to the synaptics driver to handle touchpads
2/ xserver-xorg-input-synaptics is always installed as a dependency
of xserver-xorg-input-all
3/ gnome-control-center 3.20 uses libinput and no longer support synaptics

Clearly points 1 and 2 are in conflict: the upstream explanation is that that the
package should not be installed by default and we do install it by default.

Looking at https://anonscm.debian.org/cgit/pkg-xorg/debian/xorg.git I see
that we have unreleased changes to not install the synaptics driver by
default. Timo or Emilio, can you upload those changes?

Even with this driver no longer installed by default, this will not fix
the setup for users who are upgrading. Do you have any suggestion on how
we should handle upgrades?

My best idea right now is that gnome-control-center's postint should
do something like this:
if [ -e /usr/share/X11/xorg.conf.d/60-libinput.conf ] && \
dpkg -s xserver-xorg-input-synaptics >/dev/null 2>&1 && \
[ ! -e /etc/X11/xorg.conf.d/90-libinput.conf ]
then
echo "Creating /etc/X11/xorg.conf.d/90-libinput.conf to workaround xserver-xorg-input-synaptics"
mkdir -p /etc/X11/xorg.conf.d
ln -sf /usr/share/X11/xorg.conf.d/60-libinput.conf /etc/X11/xorg.conf.d/90-libinput.conf
fi

And it should add a README.debian explaining that
/etc/X11/xorg.conf.d/90-libinput.conf can be replaced with an empty file
if you want to let the synaptics driver to take precedence.

The other solution is to add a "Conflicts: xserver-xorg-input-synaptics"
but this is rather extreme. Although it is somewhat in line with
the upstream views on the topic.

The best solution would be to have gnome-control-center handle properly
synaptics-managed touchpads but I don't think that upstream developers are
very open to that idea given that they have dropped the support on
purpose.

What do you think?

I also wonder what is the status of libinput support in other desktop
environments. Do KDE/XFCE/LXDE/MATE/Cinnamon/... properly configure
touchpads managed with the libinput driver? If not, then the removal of
the synaptics driver is likely to negatively affect them.

In any case, I would like to see this fixed soon as we have many users bitten
by this (I got many reports on Kali) and I'm willing to help where needed.

[1] Upstream tickets somewhat related:
https://bugzilla.gnome.org/show_bug.cgi?id=747956
https://bugzilla.gnome.org/show_bug.cgi?id=764257

[2] https://lists.x.org/archives/xorg-devel/2016-May/thread.html#49782
http://anonscm.debian.org/cgit/pkg-xorg/driver/xserver-xorg-input-synaptics.git/commit/?id=ca44e3fbf8271712db94bf8f38e363f34b7e33af
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[Emilio Pozuelo Monfort]

On 11/07/16 16:34, Raphael Hertzog wrote:
> [ Bcc debian-x and debian-gtk-gnome, discussion on -devel as the topic
> crosses the boundaries of multiple teams ]
>
> Hello,
>
> it has been some time that GNOME 3.20 users have been unable to configure
> their touchpad[1] because:
> 1/ xserver-xorg-input-synaptics cherry-picked an upstream commit[2]
> that gives the priority to the synaptics driver to handle touchpads
> 2/ xserver-xorg-input-synaptics is always installed as a dependency
> of xserver-xorg-input-all
> 3/ gnome-control-center 3.20 uses libinput and no longer support synaptics
>
> Clearly points 1 and 2 are in conflict: the upstream explanation is that that the
> package should not be installed by default and we do install it by default.
>
> Looking at https://anonscm.debian.org/cgit/pkg-xorg/debian/xorg.git I see
> that we have unreleased changes to not install the synaptics driver by
> default. Timo or Emilio, can you upload those changes?

That would break non-GNOME installations as you said. We should find a good
solution before breaking more stuff.

> Even with this driver no longer installed by default, this will not fix
> the setup for users who are upgrading. Do you have any suggestion on how
> we should handle upgrades?
>
> My best idea right now is that gnome-control-center's postint should
> do something like this:
> if [ -e /usr/share/X11/xorg.conf.d/60-libinput.conf ] && \
> dpkg -s xserver-xorg-input-synaptics >/dev/null 2>&1 && \
> [ ! -e /etc/X11/xorg.conf.d/90-libinput.conf ]
> then
> echo "Creating /etc/X11/xorg.conf.d/90-libinput.conf to workaround xserver-xorg-input-synaptics"
> mkdir -p /etc/X11/xorg.conf.d
> ln -sf /usr/share/X11/xorg.conf.d/60-libinput.conf /etc/X11/xorg.conf.d/90-libinput.conf
> fi

Please no.

> The other solution is to add a "Conflicts: xserver-xorg-input-synaptics"
> but this is rather extreme. Although it is somewhat in line with
> the upstream views on the topic.

Not that either.

> The best solution would be to have gnome-control-center handle properly
> synaptics-managed touchpads but I don't think that upstream developers are
> very open to that idea given that they have dropped the support on
> purpose.
>
> What do you think?

We thought about backporting synaptics support back for Stretch, to give more
time to libinput to mature and to other DEs to add support for it. Not sure how
much work that would be though.

The other good option I can think of is to make GNOME prefer libinput by passing
some options to X through gdm. No idea how feasible that is.

Cheers,
Emilio

[Raphael Hertzog]

Hi,

Ok, let's try to convince upstream then, I filed this:
https://bugzilla.gnome.org/show_bug.cgi?id=768682

Feel free to expand if I forgot some important point.

> The other good option I can think of is to make GNOME prefer libinput by passing
> some options to X through gdm. No idea how feasible that is.

It would still break KDE or XFCE started by gdm then.

Cheers,

[Michael Biebl]

Hi

Am 11.07.2016 um 18:41 schrieb Raphael Hertzog:
> On Mon, 11 Jul 2016, Emilio Pozuelo Monfort wrote:
>> The other good option I can think of is to make GNOME prefer libinput by passing
>> some options to X through gdm. No idea how feasible that is.
>
> It would still break KDE or XFCE started by gdm then.

Well, gdm would obviously only do that for a GNOME3 session, otherwise
it would be pretty pointless.
But starting GNOME from lightdm or kdm would still lead to a broken
behaviour. So this approach would only be a partial solution.

Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Raphael Hertzog]

On Mon, 11 Jul 2016, Emilio Pozuelo Monfort wrote:

> > Looking at https://anonscm.debian.org/cgit/pkg-xorg/debian/xorg.git I see
> > that we have unreleased changes to not install the synaptics driver by
> > default. Timo or Emilio, can you upload those changes?
>
> That would break non-GNOME installations as you said. We should find a good
> solution before breaking more stuff.

Well, if some KDE/XFCE/etc. packages work only with synaptics and not with
libinput, then we should get those packages updated to depend on
xserver-xorg-input-synaptics, no?

This seems a better course of action than keeping a broken GNOME. In that
regard, having explicit dependencies seems better than keeping the
problematic dependency on xserver-xorg-input-all.

> Please no.
[...]
> Not that either.

Unless someone volunteers to create the patch that bring synaptics support
back, we must find some solution that covers at least the most common case
of having a single desktop installed and having it work as expected.

The suggestions I made fulfill that criteria, so can you elaborate on why
you don't want any of the above?

Also they could be temporary stop-gap measures until someone implements
something better... the "keep things broken until someone is annoyed
enough to work on a proper fix" is not a policy that we should use.

We're annoyed when upstream do that on us, why should we do the same with
our users?

> We thought about backporting synaptics support back for Stretch, to give more
> time to libinput to mature and to other DEs to add support for it. Not sure how
> much work that would be though.

Trying to identify relevant upstream commits on gnome-settings-daemon:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=66c211ff24bec6a938d6a6a0dd8730f4689ef383
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9287ef9ac5b119abdcbbabd920c19f353e577f90

Possibly also this one although that feature seems not important:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=c50ceb880e928506d987747f9e554079ad3d9826

All lead to https://bugzilla.gnome.org/show_bug.cgi?id=759595 which
indicates that *BSD are invited to revert the patch to properly support
synaptics/evdev. So maybe it's not too hard to revert for us as well?

In control-center, we have the following relevant commits:
https://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-20&id=ce48b5c6594ad450bbfee526683fe19efffe9ef3
https://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-20&id=796e3fba9ed206e6570d3b38e3b81cf096851568

I expect those revert patches to require some regular work going forward...

I'm starting now to prepare updated packages with the above changes
reverted... just to see how hard it is and whether it seems to work.

> The other good option I can think of is to make GNOME prefer libinput by passing
> some options to X through gdm. No idea how feasible that is.

Looking at xorg.conf(5) it seems that "-configdir" or "-config" are parsed
before /usr/share/X11/xorg.conf.d which thus would not make it possible
to inject additional configuration for this. And I believe that the X
options are common to all sessions anyway so it would require some ugly
hacks AFAIK.

Cheers,

[Emilio Pozuelo Monfort]

On 11/07/16 18:48, Michael Biebl wrote:
> Hi
>
> Am 11.07.2016 um 18:41 schrieb Raphael Hertzog:
>> On Mon, 11 Jul 2016, Emilio Pozuelo Monfort wrote:
>>> The other good option I can think of is to make GNOME prefer libinput by passing
>>> some options to X through gdm. No idea how feasible that is.
>>
>> It would still break KDE or XFCE started by gdm then.
>
> Well, gdm would obviously only do that for a GNOME3 session, otherwise
> it would be pretty pointless.

Yes, that is what I meant.

> But starting GNOME from lightdm or kdm would still lead to a broken
> behaviour. So this approach would only be a partial solution.

I thought about that, but Andreas told me that screen locking is already broken
if you don't use gdm. Dunno if that got fixed or if it's still an issue.

Emilio

[Raphael Hertzog]

On Mon, 11 Jul 2016, Raphael Hertzog wrote:
> I'm starting now to prepare updated packages with the above changes
> reverted... just to see how hard it is and whether it seems to work.

Please find attached the two patches that I came up with. The packages
compile and seem to work in so far that I can enable/disable tap-to-click
at least (I see the touchpad in control-center). In the process, I lost
double-finger scrolling that seemed to work by default before...

What does the GNOME team think? Shall I commit those changes and do we
want to maintain those patches?

[Russell Stuart]

On Mon, 2016-07-11 at 23:51 +0200, Raphael Hertzog wrote:
> Well, if some KDE/XFCE/etc. packages work only with synaptics and not
> with libinput, then we should get those packages updated to depend on
> xserver-xorg-input-synaptics, no?

I don't know about KDE/XFCE, but in the etc category is LXDE, and it
works with both.  I'd be surprised if KDE and XFCE didn't work with
both too as libinput and synaptics are drivers, and as such are hidden
by the X API these window managers use.  The surprising thing for me is
GNOME evidently isn't using the X API, but instead talking to the
driver directly.

In my case, the thing that broke when xserver-xorg briefly switched to
using libinput instead of synaptics wasn't LXDE, it was me.  The
reasons are spelled out in the bug that was filed when the change was
made:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835

Briefly: synaptics is much better touchpad driver than libinput.
 Libinput treats a touchpad as a mouse.  Modern MAC like touchpads are
great input devices, but when you strip them of multitouch and gesture
recognition they become so unwieldly people give up and plug in a real
mouse.

[Lars Wirzenius]

On Tue, Jul 12, 2016 at 09:36:16AM +1000, Russell Stuart wrote:
> Briefly: synaptics is much better touchpad driver than libinput.

For me, the opposite is true. After Raphael's mail yesterday, I
switched from the synaptics driver to the xinput one (by removing
xserver-xort-input-synaptics) and since then, I've not had a single
case of moving the mouse or clicking by tapping by accident. When the
opposite change happened a few weeks ago, the accidents started
happening with such frequency that I could barely finish a sentence in
the same window I started it. As a result, I started pulling out my
hair and when I had no hair left on my head, I switched to an external
mouse. The doctors say I should make a complete hair-recovery and my
barber is very happy about that.

So for me, the "palm detection" that the xinput driver does, is very
much better than what the synaptics driver does. This might be because
the xinput driver is less smart than the synaptics one, but the end
result for me is a massively better user experience. Tapping and
two-finger scrolling work perfectly fine with the xinput driver, too.

--
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh

[Russell Stuart]

On Tue, 2016-07-12 at 07:48 +0300, Lars Wirzenius wrote:
> After Raphael's mail yesterday, I switched from the synaptics driver
> to the xinput one (by removing xserver-xort-input-synaptics) and
> since then, I've not had a single case of moving the mouse or
> clicking by tapping by accident. When the opposite change happened a
> few weeks ago, the accidents started happening with such frequency
> that I could barely finish a sentence in the same window I started
> it.

For me at least the problem isn't palm detection, because in the end
it's a kludge that can at best only partially work.  For synaptics the
solution for this is syndaemon, and the problem it's broken right now:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818471

Maybe libinput does the typing detection syndaemon does, but I can't
find any evidence for it.

> Tapping and two-finger scrolling work perfectly fine with the xinput
> driver, too.

As a touchpad that doesn't move the mouse as I type is hugely
attractive, I tried libxinput again.  Same result.  Palm detection
works wonderfully, but only because it doesn't recognise a tap from
finger either.  Clicking (ie a tap heavy enough to activate the
mechanical switch underneath) does work.

If I configure synaptics to ignore TapButton1 taps (as opposed to
clicks), it also has faultless palm detection.

[Mike Hommey]

(Note, I don't think the drivers do anything wrt palm detection and
other things)

It's just probably that your config didn't have palm detection enabled
with the synaptics driver. `synclient | grep PalmDetect` would tell you.

Mike

[Vincent Bernat]

❦ 12 juillet 2016 06:48 CEST, Lars Wirzenius <l...@liw.fi> :

>> Briefly: synaptics is much better touchpad driver than libinput.
>
> For me, the opposite is true.

For me too. When the switch was done to libinput, my touchpad was
enabled again. I was first surprised but notice that palm detection was
pretty good and that two-finger scrolling was working out of the box. I
have a carbon X1 where the trackpoint buttons are coupled with the
touchpad. libinput handles this case perfectly and I can now scroll with
trackpoint and middle button like in older models, something that was
not possible due to stuff being handled by two different drivers.
--
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)

[Lars Wirzenius]

On Tue, Jul 12, 2016 at 02:45:49PM +0900, Mike Hommey wrote:
> It's just probably that your config didn't have palm detection enabled
> with the synaptics driver. `synclient | grep PalmDetect` would tell you.

I've been using the following script, with variations on the
parameters to find a working setup. The values below are the best I
could manage, and they aren't any good.

#!/bin/sh

synclient \
TapButton1=1 \
TapButton2=2 \
TapButton3=3 \
PalmDetect=1 \
PalmMinWidth=50 \
PalmMinZ=10 \
VertSCrollDelta=-41 \
HorizScrollDelta=-41 \
TouchpadOff=0 \
"$@"

[Lars Wirzenius]

On Tue, Jul 12, 2016 at 03:52:56PM +1000, Russell Stuart wrote:
> Maybe libinput does the typing detection syndaemon does, but I can't
> find any evidence for it.

I remember trying the typing detection some years ago. It didn't help
me much, since the order of events, for me, tend to be that the mouse
events happen first, and typing events only later, so that by the time
the typing prevents the touchpad from working it's already too late,
as the mouse has moved and sometimes clicked. (Which is a recipe for
very confusing IRC dicussions, btw.)

[Russell Stuart]

On Tue, 2016-07-12 at 10:07 +0300, Lars Wirzenius wrote:
> I've been using the following script, with variations on the
> parameters to find a working setup. The values below are the best I
> could manage, and they aren't any good.
>
> #!/bin/sh
>
> synclient \
> TapButton1=1 \
> TapButton2=2 \
> TapButton3=3 \
> PalmDetect=1 \
> PalmMinWidth=50 \
> PalmMinZ=10 \
> VertSCrollDelta=-41 \
> HorizScrollDelta=-41 \
> TouchpadOff=0 \
>         "$@"

For what it's worth, for me on stretch synclient isn't too reliable.
 Eg, "synclient TapButton1=0" has no effect - it should disable one
fingered taps.  The libxinput equivalent (xinput --set-prop) doesn't
work for libxinput either.

The only thing that has proved reliable is putting a file in
/etc/X11/xorg.conf.d/touchpad.conf:

Section "InputClass"
  Identifier "Touchpad twofinger scroll"
  MatchIsTouchpad "yes"
  Driver "synaptics"
  Option "ZAxisMapping" "4 5"
  Option "HorizTwoFingerScroll" "true"
  Option "VertTwoFingerScroll" "true"
  Option "FastTaps" "on"
  Option "PalmDetect" "on"
  Option "AccelFactor" "0.1028806" #2x
  Option "AdaptiveDeceleration" "10"
  Option "MinSpeed" "0.5"
  Option "MaxSpeed" "4.75"
  Option "TapButton1" "1"
  Option "TapButton2" "3"
  Option "TapButton3" "2"
EndSection

I would happily use libxinput if it extricated me from this mess, but
right now it seems to be bugs all the way down.

[Raphael Hertzog]

On Mon, 11 Jul 2016, Raphael Hertzog wrote:
> > We thought about backporting synaptics support back for Stretch, to give more
> > time to libinput to mature and to other DEs to add support for it. Not sure how
> > much work that would be though.
>
> Ok, let's try to convince upstream then, I filed this:
> https://bugzilla.gnome.org/show_bug.cgi?id=768682

Upstream rejected the request. At the same time, someone pointed
out that KDE supports libinput. Russel Stuart in
<1468280176.5...@stuart.id.au> told us that LXDE supports
libinput as well. I checked the git history of XFCE and also
found indication that libinput was supported.

I don't know about others DE, but I believe that we're sufficiently
covered here with GNOME/KDE/XFCE/LXDE to be able to go ahead with the release of
xserver-xorg-input-all dropping the synaptics/evdev driver.

[Guus Sliepen]

On Mon, Jul 11, 2016 at 04:34:22PM +0200, Raphael Hertzog wrote:

> it has been some time that GNOME 3.20 users have been unable to configure
> their touchpad[1] because:
> 1/ xserver-xorg-input-synaptics cherry-picked an upstream commit[2]
> that gives the priority to the synaptics driver to handle touchpads
> 2/ xserver-xorg-input-synaptics is always installed as a dependency
> of xserver-xorg-input-all
> 3/ gnome-control-center 3.20 uses libinput and no longer support synaptics

I'm using XFCE, and recently when an apt-get upgrade caused the X server
to use libinput instead of the synaptics driver, I had a very difficult
time getting my touchpad configured correctly, in the end causing me to
move back to the synaptics driver. There are several issues with moving
from synaptics to libinput:

1) The defaults are different. Depending on your touchpad, that might
make things better or worse. This will cause people to be taken by
surprise and then they will have to figure out how to configure it with
the new system.

2) Configuring your touchpad in a desktop environment independent way is
harder with libinput than with synclient. Although far from perfect, the
synclient tool is much easier to use than either xinput --set-prop or
editing the Xorg.conf file.

--
Met vriendelijke groet / with kind regards,
Guus Sliepen <gu...@debian.org>

[殷啟聰]

Hi everyone,

I don't know if this as a feedback from a user helps. If you login GNOME in Wayland session, the touchpad settings comes back to the control panel. I have been using GNOME on Wayland for several weeks and nothing is bad.

Probably making Wayland the default GNOME session is the simplest (but impractical, probably) solution to this?

Cheers,

Kai-Chung Yan

Raphael Hertzog <her...@debian.org> 於 2016年7月12日 星期二寫道：

--
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/

[Simon McVittie]

On Tue, 12 Jul 2016 at 12:52:08 +0200, 殷啟聰 wrote:
> Probably making Wayland the default GNOME session is the simplest (but
> impractical, probably) solution to this?

I think GNOME 3.20 on Wayland still has too many "papercuts" to be
something we can support as a long-term default. I'm using it myself,
and I've been fixing some of them (mainly those that have an impact on
gnome-terminal), but others are more involved and are beyond my ability
to fix.

Many of the remaining issues with Wayland are not things we can
realistically fix downstream, because they need new protocol development
that has to be coordinated with Wayland and/or GNOME upstream developers
(depending whether it's a standardized protocol or something that can
reasonably be GNOME-specific).

GNOME 3.22 will be released before squeeze freezes, and will hopefully do
Wayland better (each GNOME 3 release so far has done Wayland significantly
better than the last). The Fedora developers are aiming to default
to Wayland for their release that uses GNOME 3.22 - but I'm not sure
how much weight to put on that, because they've been hoping to default
to Wayland for several Fedora releases now, and so far they've always
decided closer to their release that it wasn't ready.

If you test GNOME Shell on Wayland, please usertag your bug reports
to appear in
<https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-...@lists.alioth.debian.org;tag=wayland>
so we can keep track of how numerous and severe the issues are.

S

[Ian Jackson]

Guus Sliepen writes ("Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics"):

> I'm using XFCE, and recently when an apt-get upgrade caused the X server
> to use libinput instead of the synaptics driver, I had a very difficult
> time getting my touchpad configured correctly, in the end causing me to
> move back to the synaptics driver. There are several issues with moving
> from synaptics to libinput:
>
> 1) The defaults are different. Depending on your touchpad, that might
> make things better or worse. This will cause people to be taken by
> surprise and then they will have to figure out how to configure it with
> the new system.

At the very least I don't think this change should be made to any
existing systems.

People learn how their touchpad works, and they learn to work around
(or how to configure away) whatever things irritate them personally.

We should not be asking people to redo that on upgrades. At least if
they reinstall they maybe have the old install as a reference.

Thanks,
Ian.

(who uses a home-modified xserver-xorg-input-mtrack)

[Adam D. Barratt]

On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
> GNOME 3.22 will be released before squeeze freezes

That seems a little unlikely. :)

Regards,

Adam

[Adam Borowski]

On Tue, Jul 12, 2016 at 06:39:28PM +0100, Adam D. Barratt wrote:
> On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
> > GNOME 3.22 will be released before squeeze freezes
>
> That seems a little unlikely. :)

Yeah, it was a mistake to name two close releases such similar names.
We should have gone with zurg. :ş

--
An imaginary friend squared is a real enemy.

[Dimitri John Ledkov]

On 12 July 2016 at 19:29, Adam Borowski <kilo...@angband.pl> wrote:
> On Tue, Jul 12, 2016 at 06:39:28PM +0100, Adam D. Barratt wrote:
>> On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
>> > GNOME 3.22 will be released before squeeze freezes
>>
>> That seems a little unlikely. :)
>
> Yeah, it was a mistake to name two close releases such similar names.
> We should have gone with zurg. :ş
>

Yeap, zurg is the best. And the next two are close as well: buster & bullseye

--
Regards,

Dimitri.

[Russell Stuart]

On Thu, 2016-07-14 at 13:41 +1000, Peter Hutterer wrote:

Thanks for the thorough analysis.

> The second component is that apparently tapping doesn't work when
> enabled. That's most probably a bug, file one against libinput at
> bugs.freedesktop.org and it'll get fixed.

Done.  Having to filing it against a Wayland component was novel, and
encouraging.

[Peter Hutterer]

[Disclaimer: I'm jumping in because of the LWN quote of the week and I'm
just reconstructing the emails from the archives, I'm not subscribed.
Apologies if the thread breaks or any other side effects. Please keep me in
CC]

On Tue, Jul 12, 2016 at 09:36:16AM +1000, Russell Stuart wrote:

> On Mon, 2016-07-11 at 23:51 +0200, Raphael Hertzog wrote:
> > Well, if some KDE/XFCE/etc. packages work only with synaptics and not
> > with libinput, then we should get those packages updated to depend on
> > xserver-xorg-input-synaptics, no?
>
> I don't know about KDE/XFCE, but in the etc category is LXDE, and it
> works with both. I'd be surprised if KDE and XFCE didn't work with
> both too as libinput and synaptics are drivers, and as such are hidden
> by the X API these window managers use. The surprising thing for me is
> GNOME evidently isn't using the X API, but instead talking to the
> driver directly.

You're misinterpreting things here. GNOME is using the X device property API
to talk to the driver - the same way as it does for synaptics or anything
else. The property API is a generic key/value API (see XIChangeProperty) and
when you set properties you have to know which format to set. It's the same
API the xinput tool uses (and synclient, syndaemon, xsetwacom, etc.)

The reason why supporting both drivers is because the properties are highly
driver specific. If you want to enable tap-to-click on synaptics, you need
to set the fifth, sixth and seventh byte of the "Synaptics Tap Action"
property to 1, 3 and 2, respectively. This is exactly what g-s-d and any
other config tool did before.

libinput has different configuration options. We discussed making it 1:1
compatible but it was deemed impossible, especially given how little benefit
we would get from it. So xf86-input-libinput's properties are different -
e.g. tapping is enabled by setting the boolean "libinput Tapping Enabled"
property to 1.

also note: xf86-input-libinput is the X driver that wraps "libinput the
library", we tend to use the two interchangably though, especially in the X
context. the X driver has very little functionality beyond mapping between X
and libinput APIs.

> In my case, the thing that broke when xserver-xorg briefly switched to
> using libinput instead of synaptics wasn't LXDE, it was me. The
> reasons are spelled out in the bug that was filed when the change was
> made:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835
>
> Briefly: synaptics is much better touchpad driver than libinput.
> Libinput treats a touchpad as a mouse. Modern MAC like touchpads are
> great input devices, but when you strip them of multitouch and gesture
> recognition they become so unwieldly people give up and plug in a real
> mouse.

That statement is false. We have plenty of documentation online that
explains what we do with touchpads.
https://wayland.freedesktop.org/libinput/doc/latest/touchpads.html
The only features I can think of that definitely don't work anymore are
circular scrolling and corner tapping. I think everything else is supported,
albeit not always in exactly the same manner as synaptics did. Tapping,
two-finger scrolling, edge scrolling, etc. they're all supported.
Speaking of gesture recognition: we have actual gesture recognition in
libinput, something synaptics never had (beyond two-finger scrolling).
See https://wayland.freedesktop.org/libinput/doc/latest/gestures.html

back to the bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835

there are two components to this bug: one is that you're using synclient
which is a tool specifically written to interact with the synaptics driver.
Historical fact: it used to use shm to communicate with the driver before I
added the device properties to the server (~8 years ago).
As an analogy: fsck.ext3 won't work on btrfs either.

syndaemon is the same, it monitors the events in the server and uses
synaptics-specific properties to disable the touchpad. This isn't needed
anymore in libinput and the equivalent disable-while-typing feature is
enabled by default.

The second component is that apparently tapping doesn't work when enabled.
That's most probably a bug, file one against libinput at
bugs.freedesktop.org and it'll get fixed.

Cheers,
Peter

[Peter Hutterer]

[Disclaimer: I'm jumping in because of the LWN quote of the week and I'm
just reconstructing the emails from the archives, I'm not subscribed.
Apologies if the thread breaks or any other side effects. Please keep me in
CC]

On Tue, 2016-07-12 at 07:48 +0300, Lars Wirzenius wrote:

> For me, the opposite is true. After Raphael's mail yesterday, I
> switched from the synaptics driver to the xinput one (by removing

point of order :)
- synaptics == xf86-input-synaptics == old X touchpad driver
- libinput == the library to handle libinput, used by wayland compositors and
- xf86-input-libinput == the X driver wrapping libinput, though for simplicity
in most X context worring about the difference between the driver and
libinput doesn't matter
- xinput == a commandline tool to change X device properties and a couple of
other X Input Extension calls.

There's no "xinput" driver, and xinput is similar to tools like gsettings,
it has no knowledge of the other end, the properties API is a generic one.

synclient is a synaptics-specific tool that uses the same API that xinput
uses but because it's synaptics specific it can have a more 'intuitive'
interface. (haha. as if TapButton1 was intuitive. anyway, you get the gist :)

> xserver-xort-input-synaptics) and since then, I've not had a single
> case of moving the mouse or clicking by tapping by accident. When the
> opposite change happened a few weeks ago, the accidents started
> happening with such frequency that I could barely finish a sentence in
> the same window I started it. As a result, I started pulling out my
> hair and when I had no hair left on my head, I switched to an external
> mouse. The doctors say I should make a complete hair-recovery and my
> barber is very happy about that.
>
> So for me, the "palm detection" that the xinput driver does, is very
> much better than what the synaptics driver does. This might be because
> the xinput driver is less smart than the synaptics one, but the end
> result for me is a massively better user experience. Tapping and
> two-finger scrolling work perfectly fine with the xinput driver, too.

libinput is a lot smarter than synaptics when it comes to palm
detection. there's only so much we can do with the data we get from
touchpads (it's pretty terrible) but the couple of things we do are:
we look for touches in areas on the touchpads that are likely palms and
monitor those touches. If they exhibit palm behaviour we ignore them.
And the touchpad monitors the keyboard and the trackstick (if any) for
activity and disables itself, depending on the input (without the need for
an external process like syndaemon). There are a couple of details synaptics
never had, for example if you rest your palm on the touchpad while typing
that palm won't generate touch events. But if you start a touch immediately
after the last key press that finger *will* generate touch events.
Both are common scenarios that need special treatment.

https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

Cheers,
Peter

[Russell Stuart]

On Thu, 2016-07-14 at 14:13 +1000, Russell Stuart wrote:
> The second component is that apparently tapping doesn't work when
> > enabled. That's most probably a bug, file one against libinput at
> > bugs.freedesktop.org and it'll get fixed.
>
> Done.

For anyone still following along it is possible to get libinput to work
as least as well synaptics on my laptop (and I presume all others):

    https://bugs.freedesktop.org/show_bug.cgi?id=96925#c6

Short form: there are bugs somewhere, but you can work around them.

[Theodore Ts'o]

On Thu, Jul 14, 2016 at 01:57:13PM +1000, Peter Hutterer wrote:
> libinput is a lot smarter than synaptics when it comes to palm
> detection.

Question about libinput? The main reason why I'm using synclient
because I have a Thinkpad T540p which doesn't have hard buttons for
the "mouse buttons". It does have TrackPoint which I infinitely
prefer to the !@#?! horrendo Trackpad on the T540p. So I do the
following to only use the Trackpad for buttons.

synclient RightButtonAreaTop=0
synclient RightButtonAreaRight=4858
synclient RightButtonAreaBottom=5000
synclient RightButtonAreaLeft=3500

synclient MiddleButtonAreaTop=0
synclient MiddleButtonAreaRight=3499
synclient MiddleButtonAreaBottom=5000
synclient MiddleButtonAreaLeft=2800

synclient coastingFriction=50
synclient coastingSpeed=15

synclient areaTopEdge=6000
synclient areaLeftEdge=0
synclient VertEdgeScroll=0
synclient HorizEdgeScroll=0

Basically, I don't want to use the Trackpad for mouse events, not
*ever*. And even if the keyboard and trackpoint are quiscent, I don't
want a random palm swipe to be registered a mouse or button event ---
only when the pad is physically depressed.

What's the equivalent way of doing the same thing with the libinput
driver? (Note: I'm still using the X server, not Wayland, and I'm
using XFCE).

Thanks,

- Ted

[Peter Hutterer]

At runtime:
xinput set-prop "libinput Send Events Modes Enabled" 1 0

Static config:
cat > /etc/X11/xorg.conf.d/99-libinput-disable-touchpad.conf
Section "InputClass"
Identifier "disable touchpad"
MatchDriver "libinput"
MatchIsTouchpad "on"
Option "SendEventsMode" "disabled"
EndSection

Any typos in the above are of course fully intended ;)

Long explanation: libinput doesn't have a concept of disabling a device
because in some cases (like the T540 series) a disabled device still
needs to send events. So we named the "send events mode", i.e. it
decides whether the device will send events or not.

On the Lenovo *40 series, libinput reroutes top button events already
anyway, those buttons always come out of the trackpoint device.
when you disable the touchpad the top software buttons will still work
since they are logically part of some other device. We'll also
automatically increase the button area in that case to make the buttons
easier to hit.

Cheers,
Peter

[Arto Jantunen]

Peter Hutterer <peter.h...@who-t.net> writes:
> [Disclaimer: I'm jumping in because of the LWN quote of the week and I'm
> just reconstructing the emails from the archives, I'm not subscribed.
> Apologies if the thread breaks or any other side effects. Please keep me in
> CC]

After this list discussion I switched my laptop from the synaptics
driver to the new libinput driver. Most things just work (after
re-enabling tap to click), but one thing I can't seem to figure out.

Is it possible to remap two finger tap to the middle button (button 2)
without remapping the right side of the clickpad at the same time
(set-button-map seems to only do both at a time)? Searching finds
several people asking this question, but sadly no responses.

Also it might be nice to clear up some of the confusion the KDE people
seem to have about this change ("libinput removes all touchpad
configuration options except clicking enabled and scrolling", while many
of the options remain available via the nice and friendly userinterface
of xinput [1]).

[1] https://rajeeshknambiar.wordpress.com/2015/02/22/libinput-support-added-to-touchpad-kcm/

--
Arto Jantunen

[Peter Hutterer]

On Sun, Jul 17, 2016 at 02:56:50PM +0300, Arto Jantunen wrote:
> Peter Hutterer <peter.h...@who-t.net> writes:
> > [Disclaimer: I'm jumping in because of the LWN quote of the week and I'm
> > just reconstructing the emails from the archives, I'm not subscribed.
> > Apologies if the thread breaks or any other side effects. Please keep me in
> > CC]
>
> After this list discussion I switched my laptop from the synaptics
> driver to the new libinput driver. Most things just work (after
> re-enabling tap to click), but one thing I can't seem to figure out.
>
> Is it possible to remap two finger tap to the middle button (button 2)
> without remapping the right side of the clickpad at the same time
> (set-button-map seems to only do both at a time)? Searching finds
> several people asking this question, but sadly no responses.

no, the assignment is currently hardcoded. But this bug got filed over the
weekend, so it's probably best to move the discussion there.
https://bugs.freedesktop.org/show_bug.cgi?id=96962

> Also it might be nice to clear up some of the confusion the KDE people
> seem to have about this change ("libinput removes all touchpad
> configuration options except clicking enabled and scrolling", while many
> of the options remain available via the nice and friendly userinterface
> of xinput [1]).
>
> [1] https://rajeeshknambiar.wordpress.com/2015/02/22/libinput-support-added-to-touchpad-kcm/

look at the date on that post. we've added a bunch of options since.
but what we didn't (and still don't) do is to re-add everything the
synaptics driver exposed just so we have configuration options. there is a
school of thought that configuration is good for configuration's sake. and
that's just not true. there are some configurations that are important
because they are common and highly-divided user-specific preferences
(eg. tapping on or off). There are some configuration options that are
hardware-dependent like the top software buttons on the Lenovo *40 series.
libinput doesn't expose those, we only enable them on the hardware where it
matters. Other configuration options are required because while they
shouldn't be a config option, we (in libinput) don't have enough context
when to enable or disable them. that's why disable-while-typing can be
turned off - we don't know whether keyboard input is 'typing, please disable
touchpad' or 'playing a game, please leave touchpad enabled'. And there are
some features that are important to some users while making it impossible or
hard for others to interact (tap drag-lock).

So with any config options, we look at which bucket the config falls and
then decide whether to expose it. Somethimes the decision is easy,
often it's not, sometimes you'll disagree, sometimes you won't :)
just remember, configuration options come at a cost and it's usually the
maintainers who pay the price. and removing a config option is always more
controversial than adding one.

Cheers,
Peter

[Graziano Obertelli]

On Sun, 2016-07-17 at 14:56 +0300, Arto Jantunen wrote:
> Peter Hutterer <peter.h...@who-t.net> writes:
> >
> > [Disclaimer: I'm jumping in because of the LWN quote of the week
> > and I'm
> > just reconstructing the emails from the archives, I'm not
> > subscribed.
> > Apologies if the thread breaks or any other side effects. Please
> > keep me in
> > CC]
>
> After this list discussion I switched my laptop from the synaptics
> driver to the new libinput driver. Most things just work (after
> re-enabling tap to click), but one thing I can't seem to figure out.

As another 'me too', like Arto I switched to libinput after seeing this
discussion, and with the switch I finally got back my touch to click
and everything else. It seems like the synaptics driver didn't worked
as well on my laptop (Dell Latitude 7350).

[Arto Jantunen]

Peter Hutterer <peter.h...@who-t.net> writes:

> On Sun, Jul 17, 2016 at 02:56:50PM +0300, Arto Jantunen wrote:
>> Is it possible to remap two finger tap to the middle button (button 2)
>> without remapping the right side of the clickpad at the same time
>> (set-button-map seems to only do both at a time)? Searching finds
>> several people asking this question, but sadly no responses.
>
> no, the assignment is currently hardcoded. But this bug got filed over the
> weekend, so it's probably best to move the discussion there.
> https://bugs.freedesktop.org/show_bug.cgi?id=96962

Ok.

>> Also it might be nice to clear up some of the confusion the KDE people
>> seem to have about this change ("libinput removes all touchpad
>> configuration options except clicking enabled and scrolling", while many
>> of the options remain available via the nice and friendly userinterface
>> of xinput [1]).
>>
>> [1] https://rajeeshknambiar.wordpress.com/2015/02/22/libinput-support-added-to-touchpad-kcm/
>
> look at the date on that post. we've added a bunch of options since.
> but what we didn't (and still don't) do is to re-add everything the
> synaptics driver exposed just so we have configuration options.

Despite the date AFAICT that blog post still accurately describes the
current state of the KDE touchpad configuration tool. I'm trying to
argue that it should expose the same options as xinput does, not that
more options need to be added to the driver itself. I didn't realise
that many of the options currently available have been added more
recently.

--
Arto Jantunen

[Peter Hutterer]

I admit I haven't looked at the KDE tool since so I can't comment on it too
much. fwiw, the list of configuration options exported by libinput is here:
https://wayland.freedesktop.org/libinput/doc/latest/group__config.html
Note that unlike synaptis/evdev, not every option is available on every
device though. for example you won't get configurable click methods on
touchpads with physical buttons.

Cheers,
Peter