Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
[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
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
[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
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
On 17/07/2016 05:49 , Theodore Ts'o wrote: 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). 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
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
On Sun, Jul 17, 2016 at 02:56:50PM +0300, Arto Jantunen wrote:
> Peter Hutterer 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
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
On Wed, Jul 20, 2016 at 12:54:05PM +0300, Arto Jantunen wrote:
> Peter Hutterer 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.
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
