<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#c6">Comment # 6</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>Created <a href="attachment.cgi?id=139319" name="attach_139319" title="results with different scaling approaches">attachment 139319</a> <a href="attachment.cgi?id=139319&action=edit" title="results with different scaling approaches">[details]</a> results with different scaling approaches Here are results of my attempts with libinput-debug-gui. I added some printfs trackpoint_accelerator_filter() in to obtain the values and plotted the results. The columns in the text file are 1: unaccelerated->x, 2: unaccelerated->y, 3: scaled.x, 4: scaled.y, 5: delta, 6: f, 7: coords.x, 8: coords.y, where variable names are from trackpoint_accelerator_filter(). The png files are plots of coords.x, coords.y (the final result), delta, and the accel factor f (result of trackpoint_accel_profile()). .txt and .png files of the same basename relate to each other. In every attempt, I first tried to move the pointer from its start position to the square grid figure above left of the start position, and tried as well as I could to place the pointer on one grid point, using gentle movements. Then I made fast movements up and down. The individual cases are: A) accel_factor_8: factor 1/8 applied to the end result of trackpoint_accel_profile(). This was your suggestion if I understood right. B) accel_factor_16: likewise, with 1/16 C) accel_factor_nomax_8: like accel_factor_8, but division by 8 before the min(factor, max_accel) operation. D) accel_factor_nomax_16: like accel_factor_nomax_8, with factor 1/16. E) scale_factor_8: factor 1/8 applied to raw values in trackpoint_normalize_deltas(). All of this was done without setting LIBINPUT_ATTR_TRACKPOINT_RANGE which was thus at the default. accel_filter->scale_factor was 1 except for (E), where it was effectively 1/8. In case A) and C), I didn't succeed to place the pointer in the grid as wanted. You can see that the final X,Y values in the plots quickly rise to values >5, making exact pointer placement impossible. B) and D) were better, but still not good. OTOH, in particular in B), the max speed that could be reached for strong movements was noticeably limited. You can see that the factor f is basically constant in case A) and B), so effectively no dynamic acceleration profile is applied. Subjectively, E) was by far the best scenario. Not a big surprise, it's equivalent to the kernel patch that I'd made. You can see in the picture that the inital X,Y outputs are very small, enabling me to place the pointer exactly where I wanted (presision was better than even in B). Yet big movements were nicely accelerated.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>