<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><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">106323</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>ALPS SS5 (SS4 v2) trackpoint too fast / jumpy because of readout "hole" in the center
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>major
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>libinput
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mwilck@suse.de
</td>
</tr></table>
<p>
<div>
<pre>On the DELL E7470, the trackpoint (an ALPS SS5 - aka SS4 v2 - DualPoint touch
pad / touch stick) is extremely jumpy and fast. libinput sees this device as
"AlpsPS/2 ALPS DualPoint Stick". Selecting small entities like letters or words
in a terminal is practically impossible.
I am positive that this effect is always present on the DELL E7470, which is
used a lot in our company as workplace laptop. I am not certain about other
laptops with this trackpoint model.
The "best" possible set of settings that I've found for current libinput is
ENV{LIBINPUT_ATTR_TRACKPOINT_RANGE}="100", the "flat" acceleration profile and
a very low accel factor of -0.9 or lower, at the cost of very slow motion for
large movements. With the default adaptive acceleration profile, I couldn't get
satisfactory results.
Using the "evdev" driver under X with option "ConstantDevceleration 8" and the
linear or polynomial AcccelerationProfile works much better for this device
than anything I've achieved with libinput. In former libinput versions, I used
to set POINTINGSTICK_CONST_ACCEL=0.1 for this device and had it work almost
nicely, and was caught by surprise by the change that dropped support for this
tuning parameter.
Closer examination shows that the raw sensor readouts of the device behave in a
peculiar way.
Here's a table of raw kernel readouts rX, rY (obtained with trace_printk()) and
resulting libinput outputs lX, lY (obtained from "libinput debug-events" with
ENV{LIBINPUT_ATTR_TRACKPOINT_RANGE}="100"). rA and lA denote the abolute values
of the movement vector, sqrt(rX^2+rY^2) and sqrt(lX^2+lY^2), respectively. (*)
The values below are from a series of *very gentle* trackpoint movements up,
right, down, and left. I actually tried to make minimal movements to the extent
my fingers are able to.
time rX rY rA lx ly lA
3244.62 -4 -6 7.2 -0.07 -0.11 0.1
3244.63 -6 -10 11.7 -0.49 -0.78 0.9
3244.65 -7 -13 14.8 -1.49 -2.53 2.9
3244.66 -8 -14 16.1 -3.23 -5.56 6.4
3244.67 -8 -17 18.8 -4.62 -8.61 9.8
3244.69 -8 -18 19.7 -5.59 -11.17 12.5
3244.70 -8 -23 24.4 -6.56 -14.75 16.1
3244.71 -8 -25 26.2 -7.36 -19.09 20.5
3244.72 -8 -25 26.2 -7.36 -20.93 22.2
3244.73 -8 -21 22.5 -7.36 -21.62 22.8
3246.61 6 4 7.2 -3.25 -12.09 12.5
3246.62 6 4 7.2 -0.40 -3.78 3.8
3246.64 7 4 8.1 0.41 -0.33 0.5
3246.65 9 4 9.8 2.35 1.34 2.7
3246.66 12 4 12.6 3.32 1.56 3.7
3246.68 12 6 13.4 4.56 2.05 5.0
3246.69 13 6 14.3 6.00 2.61 6.5
3246.70 15 6 16.2 7.63 3.23 8.3
3246.71 15 7 16.6 8.64 3.93 9.5
3246.73 15 7 16.6 9.58 4.30 10.5
3246.74 15 7 16.6 10.26 4.62 11.3
3246.75 10 7 12.2 8.83 4.49 9.9
3248.41 1 7 7.1 5.29 3.61 6.4
3248.42 1 7 7.1 2.73 2.83 3.9
3248.43 -1 7 7.1 0.86 2.19 2.4
3248.45 -1 7 7.1 0.00 2.04 2.0
3248.46 -1 7 7.1 -0.15 2.04 2.0
3248.47 -2 9 9.2 -0.40 2.37 2.4
3248.49 -4 12 12.6 -0.75 3.27 3.4
3248.50 -6 17 18.0 -1.58 5.48 5.7
3248.51 -7 22 23.1 -3.11 9.82 10.3
3248.53 -7 27 27.9 -5.09 16.55 17.3
3248.53 -7 27 27.9 -6.21 21.39 22.3
3248.55 -6 26 26.7 -6.21 23.46 24.3
3248.56 -5 16 16.8 -5.75 22.08 22.8
3248.57 -2 8 8.2 -4.14 15.93 16.5
3250.16 -7 -2 7.3 -2.70 6.49 7.0
3250.18 -7 -2 7.3 -1.58 1.51 2.2
3250.19 -8 -2 8.2 -1.50 0.13 1.5
3250.20 -12 -3 12.4 -3.11 -0.82 3.2
3250.22 -17 -5 17.7 -5.22 -1.42 5.4
3250.23 -23 -9 24.7 -9.82 -3.11 10.3
3250.24 -26 -13 29.1 -16.95 -6.52 18.2
3250.26 -31 -16 34.9 -22.31 -9.89 24.4
3250.27 -32 -16 35.8 -25.76 -12.42 28.6
3250.28 -30 -9 31.3 -27.37 -12.42 30.1
3250.29 -16 -4 16.5 -25.07 -10.35 27.1
You can see that rA hardly ever drops below 7. I have tested this extensively
on this hardware, and it seems to be real - no matter how slightly I touch the
stick, the absolute value of the readouts is either 0, or at least 7-8. Without
any scaling, this means that the pointer jumps by 8 pixels for even the
slightest horizontal and vertical movements, making the pointer impossible to
control.
My first idea was to fix this in the kernel by dividing the readouts for X and
Y by 8. That makes the device actually work nicely in the first place. But the
kernel maintainers essentially recjected the patch, saying that this would
cause valuable precision to be cast away. I now reckon that the best way to
"fix" this would be dividing the raw readouts by 8.0 in user space before
applying any other acceleration or deceleration logic. This what I think the
above-mentioned settings of the "evdev" driver do, unless I'm mistaken.
The point is that correction needs to be applied to the all-important small
sensor readings which determine the precision for gentle movements.
LIBINPUT_ATTR_TRACKPOINT_RANGE doesn't seem to be suitable for this, and
neither POINTINGSTICK_SENSITIVITY. I think that LIBINPUT_ATTR_TRACKPOINT_RANGE
might work if it wasn't capped at 100. Anyway, the recommended calibration
procedure "libinput measure trackpoint-range" doesn't work for this device -
firstly it's almost impossible to carry out because the pointer moves much too
fast, and secondly the result is too low to make the device work reliably (I
made several attempts and measured 40-45, while the "best" setting for this
device is 100 or more).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>