<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - libinput 0.11.0 doesn't offer edge scrolling" href="https://bugs.freedesktop.org/show_bug.cgi?id=89381#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - libinput 0.11.0 doesn't offer edge scrolling" href="https://bugs.freedesktop.org/show_bug.cgi?id=89381">bug 89381</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>right now there's no override, this is implemented at the libinput level so the driver can't export this. for software buttons and edge scrolling it's hard to get it right by design. the horizontal scrolling bar is in the same area as the button events and we allow movement within the software buttons (given a couple of restrictions). with horizontal scrolling enabled, a lot of the features we have currently that make software buttons work nicely would start subtly breaking. For example: putting your finger down on a software button will not move the cursor. on some touchpads the vertical travel is high enough that any phys. click will trigger some movement. with scrolling enabled, that movement would need to be differentiated from scroll movement (timeouts, heuristics, all causing slower response time and some unpredictability). this also means you can leave your finger on the button area and use a second finger for moving without the button finger affecting your movement. this would not be possible with edge scrolling enabled. unlike synaptics, libinput doesn't differ between pure vertical and horizontal scrolling, once you started scrolling in one direction you get minute movements in the other direction too - this is particularly useful for "natural scrolling" when you want to manipulate content. vertical scrolling only interferes with the software buttons in the bottom right corner - but that's where the majority of right button clicks are. In addition, iirc over 90% or so of all palm touches land in the zone that is the edge scrolling zone (see the link below). these touches cannot be distinguished from real touches by pressure data or other means. so we'd have to disable palm detection in the right zone and you'd get accidental scroll events when typing. again, heuristics and timeouts can work around that but with a number of drawbacks. The T440 and upcoming T450 series are effectively unusable without palm detection. <a href="http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html">http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html</a> synaptics works, but only by accident, only on some touchpads and only given a couple of specific conditions. first - I honestly don't know what happens when you have horizontal edge scrolling and software buttons enabled. It may work, it may not, if it does work it's purely coincidental. second, synaptics doesn't have palm detection, the closest thing to it is "disable while typing" which is an external process to switch the touchpad off, based on timeout. That approach isn't possible in Wayland btw due to the better separation between clients, syndaemon is essentially a key logger. "synaptics works" is very much a YMMV depending on the hardware and use-cases. Until we find some predictable way to deal with edge scrolling, palm detection and software buttons, it won't be available on those devices. It's available where we can make it work though, e.g. it even works on a touch-enabled Wacom tablet. but tbh what we're aiming for is making 2 finger scroll good and reliable enough that you won't want edge scrolling anymore :)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>