Created attachment 1037447 [details] evemu-recording of difficult hard click Description of problem: The mouse pointer moves a lot when trying to do hard clicks with the trackpad. This makes it very difficult to click on stuff, because often the pointer has moved away from the target. Version-Release number of selected component (if applicable): 0.17.0-1.fc22 How reproducible: Very reproducible. Steps to Reproduce: 1. Try hard clicking with with touchpad Actual results: Pointer moves a lot, often missing the intended target. Expected results: I would expect the pointer to stay put while the hard click is taking place. Additional info: Attached is a recording of the events
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