<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - ALPS SS5 (SS4 v2) trackpoint too fast / jumpy because of readout "hole" in the center" href="https://bugs.freedesktop.org/show_bug.cgi?id=106323#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - ALPS SS5 (SS4 v2) trackpoint too fast / jumpy because of readout "hole" in the center" href="https://bugs.freedesktop.org/show_bug.cgi?id=106323">bug 106323</a> from <a class="email" href="mailto:mwilck@suse.de" title="Martin Wilck <mwilck@suse.de>"> Martin Wilck</a> <pre>(In reply to Peter Hutterer from <a href="show_bug.cgi?id=106323#c4">comment #4</a>) > did you try it? because the basic approach right now is: delta * factor. > What the server does is delta * constant_deceleration * factor. So whether > you add this to the factor or later doesn't really matter. I think it does matter, because if we apply the factor "late", it's applied to the maximum acceleration, too, which is bad. I don't think we should focus on mimicking the behavior of evdev + X; rather we should figure out how to make this device work nicely with libinput. And here we have the fact that the device delivers strange/unusual raw data. But you're right, I havent't had time to actually try yet. > libinput debug-gui is the best way to test these things, it can be run from > the builddir and the pointer is controlled by libinput only, so no need to > restart between recompilations. Ah, I didn't know that, thanks. I'll try.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>