<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Acceleration still too fast with slow and slow-medium finger movements" href="https://bugs.freedesktop.org/show_bug.cgi?id=101139#c31">Comment # 31</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Acceleration still too fast with slow and slow-medium finger movements" href="https://bugs.freedesktop.org/show_bug.cgi?id=101139">bug 101139</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>Hooray. The good news: based on these videos, I don't think we have a libinput *bug*, this does appear to be just a different preference. AFAICT, the movement matches what I got with the lowclip patch, at least considering the finger motion speed etc. The bad news: to accommodate for this, we'd need some new pointer acceleration profile because if *that* is your preferred behaviour, it's going to be difficult to find a middle ground between the current and your patch. Because I consider the fast pointer motion (like in your second video) to be uncontrollable, I don't even get near any target when moving fast. Adding a new profile is relatively trivial, but it opens us up to a few things: once you have two profiles, the floodgates are open for N profiles. Anyone not happy with the current profile will be pushing for another profile slightly different and that's a situation I really want to avoid. fwiw, my macos at default speed is a lot faster than the lowclip patch. And given that we have the accel range, I think the first thing to look at is moving that baseline. From what I can tell, the macos accel doesn't have that same unaccelerated plateau that we have, it seems to almost contineously linear.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>