From: Peter Hutterer <redacted>
Sent: Donnerstag, 23. Januar 2020 05:05

On Tue, Jan 21, 2020 at 05:04:57PM -0800, dmitry.torokhov@gmail.com
wrote:

quoted

On Wed, Jan 22, 2020 at 09:35:58AM +1000, Peter Hutterer wrote:

quoted

On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com

wrote:

quoted

quoted

quoted

Hi Pali,

On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:

quoted

On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1)

wrote:

quoted

quoted

quoted

quoted

quoted

Hello,

At the file
https://github.com/torvalds/linux/blob/master/drivers/input/mo
use/alps.c I've seen that values coming from the
trackpoint/trackstick are divided at some devices, which results in a

loss of precision.

quoted

quoted

quoted

quoted

quoted

As I was not lucky with the behavior of the trackpoint of my
computer I've made a fork of libinput
https://gitlab.freedesktop.org/leutwe/libinput/tree/master/
where I changed  src/filter-trackpoint.c . With this change, the

values from lib evdev are multiplied by a factor (dpToFac_au16 []). The array
element used from dpToFac_au16 [] is also the value received by evdev.

quoted

quoted

quoted

quoted

quoted

At higher forces I use a factor much higher than 1, so the undivided

value from the device would be the best for me.

quoted

quoted

quoted

quoted

quoted

In order not to change the behavior for other users, it might be

possible to change the divider at runtime via the sys- file system - like it is at
trackpoint.c and take the currently used divider as default value.

quoted

quoted

quoted

quoted

quoted

Positions at source code were I see the division:

alps_process_trackstick_packet_v3()
/*
* The x and y values tend to be quite large, and when used
* alone the trackstick is difficult to use. Scale them down
* to compensate.
*/
x /= 8;
y /= 8;

alps_process_packet_v6()
/* Divide 4 since trackpoint's speed is too fast */
input_report_rel(dev2, REL_X, (char)x / 4);
input_report_rel(dev2, REL_Y, -((char)y / 4));

Hello Dmitry!

This problem is about fact that alps.c for some ALPS devices
already truncate precision of trackpoint movement.

Tobias is unhappy with this fact and would like to get all bits
of movement information, not just some high.

But existing userspace application expects that for these
devices kernel already truncate precision and process truncated data

from kernel.

quoted

quoted

quoted

quoted

Now question is: Are we able to send to userspace input data
without doing truncation and without breaking existing applications?

It looks like that for such thing we need some userspace <-->
kernel API which disable truncating of precision.

Have you been solving similar issue for other other drivers or
in other area of input code?

Unfortunately I do not think we can automatically "recover" the
lost precision without help of libinput, which would need to tweak
the trackpoint [sysfs] property letting kernel know that it should
send original data.

Right, so the problem here is simply: we don't have write access to
sysfs and most of libinput's users don't either. For evdev devices
it's fine thanks to logind but that won't apply for anything else.
Which means that sysfs is no-go unless you want to shell-script your way

around it.

quoted

I wonder if we can do this via udev rule that [newer] libinput package
would install? I do not think we need to support multiple input stacks
on the same system at the same time, so system-wide config could work...

good point and yes, that would work. and we already do something similar
with the fuzz handling anyway. reading sysfs is usually not an issue and worst
case we can set a udev property to get around that.

From a maintainability point of view (and also in terms of runtime), it may be best to just remove the divider. In this case, users need to make the adaption, but they could do so, if desired, with respect to the Linux kernel version.

In case of libinput I think this could be done through the device quirks. https://wayland.freedesktop.org/libinput/doc/latest/device-quirks.html

Thanks,
Tobias

quoted

quoted

It's been a while since I looked at the trackpoint code but from
what I remember it's a historical mess of inter-dependencies. The
kernel driver did something, then userspace adjusted based on that,
then the kernel driver couldn't fix anything because of userspace, and

that looped 3-4 times.

quoted

quoted

libinput has the magic trackpoint multiplier quirk to work around
this deadlock but multiplying doesn't give you precision back. As an
immediate brain fart, maybe we need a "subpixel" REL_X_FRACTION

axis?

quoted

quoted

Not ideal, since every relative device other than trackpoints just
pass on device units and rely on userspace to make sense of it, so
the trackpoints will likely stay the only users of it.

Alternatively - add the sysfs file, make libinput read it and adjust
its behaviour and then eventually toggle the default. Less breakage
that way but now you're talking about a multi-year inertia. And you
rely on userspace updating with the kernel.

Or introduce a resolution field for the EV_REL scope. Not sure how
to do that either and let's be honest, it wouldn't really be set by
the kernel for most devices anyway because it doesn't scale well
(would've come in useful for the various dpi settings on mice though).

That's all I can think of right now. For any solution - the libinput
bits are the easy ones, it's the inertia and possible other input
stacks that are the killer here.

Yeah, none of the above options with new resolution, or event code
appeal to me too much.

Thanks.

--
Dmitry