[Wayland-bugs] [Bug 106323] ALPS SS5 (SS4 v2) trackpoint too fast / jumpy because of readout "hole" in the center

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106323

--- Comment #6 from Martin Wilck <mwilck at suse.de> ---
Created attachment 139319
  --> https://bugs.freedesktop.org/attachment.cgi?id=139319&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20180503/655d3f04/attachment.html>