Bug 1230441

Created attachment 1037448 [details]
repeated hard clicks

This is a recording of multiple hard clicks, without any intended mouse movement.

I think this will be a duplicate of bug 1230462. Can you test this again with the scratch build I provided there? Thanks

That scratch build improved things tremendously!

I think there's still room for improvement.

See the attached photos.  These were done with a normal paint app.  The dots were "clean" hard clicks, and the lines are "sloppy" hard clicks.  The location of the paint in the picture is roughly where the click was done on the trackpad.

Again, that build really cleaned things up.

Compare the sample from chromeos, which is a combination of "clean" and "sloppy" hard clicks: they are indistinguishable.

(Forgive me for always referencing ChromeOS, but this is a necessity for those with low dexterity, ie: my 5 year old)

Created attachment 1037792 [details]
0.17-1 libinput

Created attachment 1037793 [details]
0.17-2 libinput

Created attachment 1037794 [details]
ChromeOS hard clicks

can you be more precise on the remaining problem please? is it that the pointer moves before the click, during the click or after the click?

found it, was a simple bug in libinput. scratch build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10029272

There's two more changes that I'll need to do here but let me know how you go with this one for now anyway.

Created attachment 1038068 [details]
paint results from scratchbuild

This does seem to help in different ways over the previous scratch build.

Note in the top row: the clicks were intended to be aligned horizontally.  The resulting click was a "point", but the pointer moved on the way down, just before the click.

Also, the rest of the lines (sloppy clicks), the pointer moved up on the way up.

and another one. This should be the proper correct fix now, but tbh I'm not sure it'll change much for you here. The remaining lines are likely a different cause.
http://koji.fedoraproject.org/koji/taskinfo?taskID=10054545

What this build does is require a 5mm movement from the finger after clicking the button before we send motion events again. That avoids erroneous movements (and should help with Bug 1230462 as well).

The remaining issues probably need solving by looking at pressure build-up. The finger pinning only happens on button click, so any movement before the click will still happen. It should help with the movement after the click though.

and here's the successful koji build. sorry about that.
http://koji.fedoraproject.org/koji/taskinfo?taskID=10054551

Created attachment 1039071 [details]
paint results from scratchbuild #2

This has given the best results by far.

"Sloppy" clicks work most of the time.  Sometimes it still happens (~25%?):

a) as shown by the first row of dots that are not lined up vertically: pointer moves before click is done

b) as shown by the lines: pointer moves during the release of the click

But again, much much much much better.

Created attachment 1039078 [details]
chromeos test #2

BTW, I was able to reproduce each of these "artifacts" on chromeos.  They just don't seem to happen as often (~5-10%?).

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

(In reply to Wade Berrier from comment #12)
> a) as shown by the first row of dots that are not lined up vertically:
> pointer moves before click is done

yeah, this needs some pressure curve analysis during events to stop this from happening. Not sure yet how to do this.

> b) as shown by the lines: pointer moves during the release of the click

the patch in 0.17.0-4 now has a 3mm threshold before we unpin it after the button release. There isn't much we can do here otherwise though, for those users that use a single finger, click, then continue a larger threshold or continuous finger locking will break the behaviour. sorry

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

(In reply to Peter Hutterer from comment #15)
> (In reply to Wade Berrier from comment #12)
> > a) as shown by the first row of dots that are not lined up vertically:
> > pointer moves before click is done
> 
> yeah, this needs some pressure curve analysis during events to stop this
> from happening. Not sure yet how to do this.
> 
> > b) as shown by the lines: pointer moves during the release of the click
> 
> the patch in 0.17.0-4 now has a 3mm threshold before we unpin it after the
> button release. There isn't much we can do here otherwise though, for those
> users that use a single finger, click, then continue a larger threshold or
> continuous finger locking will break the behaviour. sorry

No worries, this is such a huge improvement, thanks!!

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

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

just FYI, I'm going to leave this bug as closed and consider it fixed, I think the improvements make it a lot better to use. There are still leftovers (see comment 15) that we'll eventually need to fix but they should be tracked in a separate bug. Feel free to file those but especially for the pressure handling
it is an upstream feature request that will take longer to handle though, so best to file this at bugs.freedesktop.org (Wayland/libinput)

Sounds good, it's much much much better, thank you!

Upstream bug filed here for leftovers:

https://bugs.freedesktop.org/show_bug.cgi?id=91097