could be fallout fron the thumb detection, see bug 1246093. If so, does https://admin.fedoraproject.org/updates/libinput-0.20.0-3.fc22 fix it?

No, libinput-0.20.0-3-fc22 did not fix this, no observed change.

Then I'll need an evemu-record please, of the touchpad with a short sequence that isn't detected correctly.

http://www.freedesktop.org/wiki/Evemu/

Created attachment 1056675 [details]
evemu-describe

Created attachment 1056676 [details]
Failed scrolling with index & fourth fingers

Created attachment 1056677 [details]
successful scrolling with index & middle fingers

ok, found it. the reason it doesn't work is that the distance between the scroll fingers is too big for 2-finger scrolling. We allow for a 30mm distance between the fingers, anything above that we use to identify pinch gestures.

You can verify this easily by running sudo libinput-debug-events and then scroll, you'll see a bunch of pinch gesture events come out of libinput. libinput's gestures were the first to land so GTK and others can rely on it. But right now the gestures are interpreted but not handled by anything, which is why you don't see any reaction on the screen. That'll change over time as the rest of the stack gets into place.

Meanwhile, I encourage you to scroll with index+middle or middle+ring instead to have a smaller distance between the two.

Thanks for investigating.

However, particularly as libinput is a new default to Fedora 22, as a user I don't think it is reasonable to expect people to change their behaviour when there are technical alternatives.  In this case, I have never used pinch features outside of a tablet, and there is no option to disable or configure it in the gnome menu.

How did you decide on 30mm? Perhaps this is too small?  Have you considered making it configurable?

My workaround is to use the Synaptics driver (1).  I suggest that you could either add an option to disable pinch, or support both pinch & scroll features by disambiguating between the two after the relative finger movement is detected.  I think this is what Apple devices do.

Finally, regarding your expectation for me to change my behaviour, is that official Fedora policy for the developer to decide subjective user behaviour?  If so, can you point me to the relevant committee decision?  Can also you point me to the decision to use libinput as the F22 default over the Synaptics driver, as I would like to investigate how that choice was made?

Thanks


Ref 1: https://ask.fedoraproject.org/en/question/69254/fedora-22-touchpad-cursor-slags-and-jumps/

30mm is a default we picked mostly by trial and error. Two-finger scrolling is usually done with the index+middle finger, spreading them out more than 30mm is unusual. it's not going to be configurable but we can talk about making it slightly larger. But having just tried this, it'd struggle to get past 35mm distance without actively spreading the fingers. So I'd be happy to increase this a bit.

In your case it's just under 36mm (and I only checked the first event) but that is caused by you using index+ring finger. So even increasing it to 35mm wouldn't help you, but that would be detrimental to the gesture detection, at least until we improve the gesture detection code.

(In reply to Richard Geary from comment #8)
> My workaround is to use the Synaptics driver (1).  I suggest that you could
> either add an option to disable pinch, or support both pinch & scroll
> features by disambiguating between the two after the relative finger
> movement is detected.  I think this is what Apple devices do.

fwiw, that is _exactly_ why we don't add configuration options for e.g. the distance between the fingers. It prevents us from adding improvements like this in the future.

> Finally, regarding your expectation for me to change my behaviour, is that
> official Fedora policy for the developer to decide subjective user
> behaviour?  If so, can you point me to the relevant committee decision? 

I encouraged you to change the behaviour because it'll work better. Why you make this into an argument about official Fedora policy and committee decisions I don't know. So let me point one thing out: I am not against you, nor am I telling you what you need to do. As the main developer of libinput I'd like it to work well for users and I'm always happy to discuss improvements. There are some things we will try to accommodate, others we can't, or won't.

> Can
> also you point me to the decision to use libinput as the F22 default over
> the Synaptics driver, as I would like to investigate how that choice was
> made?

https://fedoraproject.org/wiki/Changes/LibinputForXorg

Thanks for your feedback.  I'm glad you're open to suggested improvements. Apologies for the harsh introduction, I was expecting a stonewall telling me to change.

My first suggestion would be to more closely match the Synaptics behaviour where possible, since it's the behaviour that most users are used to.  Maybe it exists already, but creating technical documents on the behaviour of the Synaptics behaviour would be a start point, then there's a comparison of behavioural features which could be ported or approximated.  (I don't see any adverse behavioural defaults listed on the LibinputForXorg committee decision, so I presume this wasn't enumerated)

Technically, having a binary decision (based on distance) between pinching and scrolling is always going to be surprising for a subset of users.  Emitting both pinch & scroll events simultaneously might be an option, with the magnitude of the effect decreasing close to the threshold point (eg. 30mm).  I don't know if apps could cope with both events simultaneously.
Alternatively, libinput could delay the emitting of the event until subsequent movements make it not ambiguous whether it is a scroll or pinch.  The downside is the input latency might be undesireable.

As the primary libinput touchpad developer, as a high level concept do you think the default libinput behaviou should match the default Synaptics behaviour?  If not, which aspects do you think should change?

Thanks

(In reply to Richard Geary from comment #10)
> My first suggestion would be to more closely match the Synaptics behaviour
> where possible, since it's the behaviour that most users are used to.  Maybe
> it exists already, but creating technical documents on the behaviour of the
> Synaptics behaviour would be a start point, then there's a comparison of
> behavioural features which could be ported or approximated.  (I don't see
> any adverse behavioural defaults listed on the LibinputForXorg committee
> decision, so I presume this wasn't enumerated)

creating a technical document on the synaptics behaviour would be... difficult. the driver is on the verge of being unmaintainable, adding any features to it is an exercise in guesswork and hope that nothing else breaks.
one of the big differences is that synaptics tries to be generic in spite of HW differences (using magic numbers found by trial and error). So you may find out how it works on one hardware and that changes again when the axis ranges are different again. It exposes a bucketload of config options, so users can generally coerce it into something that works, but makes any changes even harder. It has a couple of virtually unfixable bugs, and at this point, I'm just fixing crashers and severe issues, but that's about it.

So one of the things you really need to discard is the assumption that synaptics works. It doesn't, not on all hardware, not for everyone, and not without custom configuration snippets (a lot of which are just blindly copied from random forums).

libinput was born from the problem that synaptics is virtually impossible to test and so full of magic that we couldn't add a Wayland backend without rewriting it.
 
> Technically, having a binary decision (based on distance) between pinching
> and scrolling is always going to be surprising for a subset of users. 
> Emitting both pinch & scroll events simultaneously might be an option, with
> the magnitude of the effect decreasing close to the threshold point (eg.
> 30mm).  I don't know if apps could cope with both events simultaneously.
> Alternatively, libinput could delay the emitting of the event until
> subsequent movements make it not ambiguous whether it is a scroll or pinch. 
> The downside is the input latency might be undesireable.

that's pretty much what libinput does. We can't emit both events (callers couldn't handle it) so we have a couple of triggers. One of which is time-based (holding without moving will eventually switch to 2fg scrolling), one is based on finger movement and one was distance based, on the assumption that if fingers are that far apart it's a pinch gesture, not a 2fg scroll where the fingers are almost always next to each other.

That last assumption was clearly not correct, but again if you only scrolled with index+middle finger (which is the common way to do this) you would have likely not noticed (especially had we picked a slightly larger distance).


> As the primary libinput touchpad developer, as a high level concept do you
> think the default libinput behaviou should match the default Synaptics
> behaviour?  If not, which aspects do you think should change?

again, "synaptics behaviour" is hard to define simply because it's quite arbitrary and not well defined on a lot of touchpads. synaptics does not do proper multi-touch tracking and it cannot do a couple of things that libinput already does (automatic disable-while-typing, thumb detection, gestures, etc.). libinput does not do a couple of features synaptics has, e.g. circular scrolling. synaptics is very hw-dependent on almost everything, libinput tends to normalize the hw away to provide the same behaviour on all touchpads (within limits of course). Starting with "behaviour like synaptics" is like the infamous "like Microsoft Word does it"

Incidentally, I use by index & ring fingers as when my hand outstretched over the touchpad my middle finger is slightly raised.  I've also had experiences with other touchpads on other OSs where it would not see the second finger if it was too close.

Given that there is a finger movement trigger for scrolling & pinching, what was the need for the distance threshold trigger?

Since touchpad scrolling is more common than pinching, perhaps you could start by emitting scrolling events, then switch to emitting pinching events if the relative distance between the fingers decreases by a threshold amount (and insufficient scrolling movement has occured)

Documenting the behaviour of the synaptics driver would be difficult.  However, just focusing on the default behaviour would simplify it reasonable, and despite the hardware differences some attempt could be made even for a handful of touchpads.  Similar efforts could be made for Windows and MacOS touchpad behaviour, since new Fedora users will likely migrate from these platforms. The net result of the research would be a touchpad behaviour which could quantitatively say it is equal or better than the competition.  This research would also apply to bug #1247257.

libinput-0.20.0-6.fc23 has been submitted as an update for Fedora 23.
https://admin.fedoraproject.org/updates/libinput-0.20.0-6.fc23

libinput-0.20.0-6.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.20.0-6.fc22

(In reply to Richard Geary from comment #12)
> Given that there is a finger movement trigger for scrolling & pinching, what
> was the need for the distance threshold trigger?

the opposite of the timer that triggers 2fg scrolling when you hold it for a while. For small movements a motion threshold is counterproductive since it's not always clear when it kicks in. If you want to scroll by one pixel, you can hold your fingers down, wait a bit, then move and the first tiny movement will trigger a scroll. For pinch, the same was achieved the distance that was considered too wide for normal 2fg scrolling.

> Since touchpad scrolling is more common than pinching, perhaps you could
> start by emitting scrolling events, then switch to emitting pinching events
> if the relative distance between the fingers decreases by a threshold amount
> (and insufficient scrolling movement has occured)

we have to assume that scrolling does something in the UI, so if we send a scroll event before we start pinching, the consistency isn't guaranteed anymore. the scroll motion may have changed the viewpoint, or the tool, or...
that's why we need to wait until we're sure what gesture we have and then go through with that.

> Documenting the behaviour of the synaptics driver would be difficult. 
> However, just focusing on the default behaviour would simplify it
> reasonable, and despite the hardware differences some attempt could be made
> even for a handful of touchpads.  Similar efforts could be made for Windows
> and MacOS touchpad behaviour, since new Fedora users will likely migrate
> from these platforms. The net result of the research would be a touchpad
> behaviour which could quantitatively say it is equal or better than the
> competition.  This research would also apply to bug #1247257.

Between Benjamin, Hans and me we have a fair amount of laptops and touchpads. The problem are the devices that aren't ones we have access to, or use-cases that we didn't see before :)

That's one of the reasons we pushed for libinput that F22. It worked really well on our devices and we were happy with it - to the point where patches slowed down. As soon as it got exposed to a wider audience we starged getting bugs and feature requests. libinput is better for it, but the time between can be a tad painful.

libinput has some of the documentation you want, but it doesn't detail every device's custom behaviour.
http://wayland.freedesktop.org/libinput/doc/latest/pages.html
I would like for this documentation to be the canonical source of information about libinput, so please feel free to add to it.


oh, and the libinput-0.20.0-6.fc22 update removes the distance threshold, so everything should work fine now. we may bring this back though once the rest of the stack can handle gestures and there is visible feedback when a pinch gesture is interpreted vs a scroll gesture. That'll take a while though.

Package libinput-0.20.0-6.fc23:
* should fix your issue,
* was pushed to the Fedora 23 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libinput-0.20.0-6.fc23'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12385/libinput-0.20.0-6.fc23
then log in and leave karma (feedback).

Confirmed, libinput-0.20.0-6 fixes the issue, thanks.

libinput-0.20.0-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

libinput-0.20.0-6.fc23 has been pushed to the Fedora 23 stable repository.  If problems still persist, please make note of it in this bug report.