# Scenario A Steps to reproduce: Start a two-finger scroll gesture, and then move one finger to the bottom of the clickpad (soft button area), Current behavior: When one finger reached the soft button area, the scroll is stopped. Wanted behavior: The scroll does not stop. # Scenario B Steps to reproduce: With two fingers placed on the soft button area, start a scroll gesture. Current behavior: No scroll. Wanted behavior: Do scroll. # Why 1. User can scroll more amount of offset in one gesture. 2. Consistency of human touch sense and human visual sense. When human performs a scroll gesture, the brain expects to see the screen scroll. If the finger moves but the screen doesn't move, the brain experiences an inconsistency, which induces a discomfort.
Scenario A should work right now, I just did this with git master and 1.10.0 and it works as expected, moving into the scroll button area does not stop the scroll. What version of libinput are you on and what movement are you trying here? Scenario B is difficult because we also have middle button emulation on the software buttons (pressing left+right simultaneously), so now we have another layer of complexity to resolve. For B, I think you're better off switching to clickfinger behaviour and thus avoiding the software button areas.
Scenario A does work! It is my mistake that I didn't check what I wrote. Sorry.
Ok, thanks for testing. I'm afraid I'll still close this as wontfix, scenario B is ... hard (read: not very reliable) and it's much easier to switch to clickfingers instead. That's the more prevalent way of interacting with touchpads these days anyway, we're showing our age a bit here.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.