[RFC] linux-input alps

[RFC] linux-input alps

[Leutwein Tobias (BEG/ENC1)]

Hello,

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

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.

At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.

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.

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));


Best regards
Tobias 

Re: [RFC] linux-input alps - loosing precision

[Pali Rohár]

On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1) wrote:
> Hello,
> 
> At the file
> https://github.com/torvalds/linux/blob/master/drivers/input/mouse/alps.c
> I've seen that values coming from the trackpoint/trackstick are divided at some devices, which results in a loss of precision.
> 
> 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.
> 
> At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.
> 
> 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.
> 
> 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.

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?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [RFC] linux-input alps - loosing precision

[dmitry.torokhov]

Hi Pali,

On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1) wrote:
> > Hello,
> > 
> > At the file
> > https://github.com/torvalds/linux/blob/master/drivers/input/mouse/alps.c
> > I've seen that values coming from the trackpoint/trackstick are divided at some devices, which results in a loss of precision.
> > 
> > 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.
> > 
> > At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.
> > 
> > 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.
> > 
> > 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.
> 
> 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.

I'm adding Peter to hear his take on this.

Thanks.

-- 
Dmitry

Re: [RFC] linux-input alps - loosing precision

[Peter Hutterer]

On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com wrote:
> Hi Pali,
> 
> On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> > On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1) wrote:
> > > Hello,
> > > 
> > > At the file
> > > https://github.com/torvalds/linux/blob/master/drivers/input/mouse/alps.c
> > > I've seen that values coming from the trackpoint/trackstick are divided at some devices, which results in a loss of precision.
> > > 
> > > 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.
> > > 
> > > At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.
> > > 
> > > 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.
> > > 
> > > 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.
> > 
> > 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.

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.

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?
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.

Cheers,
   Peter

Re: [RFC] linux-input alps - loosing precision

[dmitry.torokhov]

On Wed, Jan 22, 2020 at 09:35:58AM +1000, Peter Hutterer wrote:
> On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com wrote:
> > Hi Pali,
> > 
> > On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> > > On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1) wrote:
> > > > Hello,
> > > > 
> > > > At the file
> > > > https://github.com/torvalds/linux/blob/master/drivers/input/mouse/alps.c
> > > > I've seen that values coming from the trackpoint/trackstick are divided at some devices, which results in a loss of precision.
> > > > 
> > > > 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.
> > > > 
> > > > At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.
> > > > 
> > > > 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.
> > > > 
> > > > 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.
> > > 
> > > 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.

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...

> 
> 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.
> 
> 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?
> 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

Re: [RFC] linux-input alps - loosing precision

[Peter Hutterer]

On Tue, Jan 21, 2020 at 05:04:57PM -0800, dmitry.torokhov@gmail.com wrote:
> On Wed, Jan 22, 2020 at 09:35:58AM +1000, Peter Hutterer wrote:
> > On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com wrote:
> > > Hi Pali,
> > > 
> > > On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> > > > On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1) wrote:
> > > > > Hello,
> > > > > 
> > > > > At the file
> > > > > https://github.com/torvalds/linux/blob/master/drivers/input/mouse/alps.c
> > > > > I've seen that values coming from the trackpoint/trackstick are divided at some devices, which results in a loss of precision.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > At higher forces I use a factor much higher than 1, so the undivided value from the device would be the best for me.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > 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.
> > > > 
> > > > 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.
> 
> 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.

Cheers,
   Peter

> 
> > 
> > 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.
> > 
> > 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?
> > 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

RE: [RFC] linux-input alps - loosing precision

[Leutwein Tobias (BEG/ENC1)]

> From: Peter Hutterer <peter.hutterer@who-t.net>
> Sent: Donnerstag, 23. Januar 2020 05:05
> 
> On Tue, Jan 21, 2020 at 05:04:57PM -0800, dmitry.torokhov@gmail.com
> wrote:
> > On Wed, Jan 22, 2020 at 09:35:58AM +1000, Peter Hutterer wrote:
> > > On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com
> wrote:
> > > > Hi Pali,
> > > >
> > > > On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> > > > > On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1)
> wrote:
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > At higher forces I use a factor much higher than 1, so the undivided
> value from the device would be the best for me.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > 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.
> >
> > 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

> >
> > >
> > > 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.
> > >
> > > 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?
> > > 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

Re: [RFC] linux-input alps - loosing precision

[Peter Hutterer]

On Thu, Jan 23, 2020 at 09:25:49AM +0000, Leutwein Tobias (BEG/ENC1) wrote:
> > From: Peter Hutterer <peter.hutterer@who-t.net>
> > Sent: Donnerstag, 23. Januar 2020 05:05
> > 
> > On Tue, Jan 21, 2020 at 05:04:57PM -0800, dmitry.torokhov@gmail.com
> > wrote:
> > > On Wed, Jan 22, 2020 at 09:35:58AM +1000, Peter Hutterer wrote:
> > > > On Tue, Jan 21, 2020 at 01:34:41PM -0800, dmitry.torokhov@gmail.com
> > wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Fri, Jan 17, 2020 at 10:42:06AM +0100, Pali Rohár wrote:
> > > > > > On Thursday 09 January 2020 14:26:16 Leutwein Tobias (BEG/ENC1)
> > wrote:
> > > > > > > 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.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > At higher forces I use a factor much higher than 1, so the undivided
> > value from the device would be the best for me.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > 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.
> > >
> > > 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.

checking the kernel version is unreliable given the various backports and
stable patches. And note that when you remove the divider, you're still
breaking all of userspace that hasn't adjusted yet. In some cases (*cough*
libinput) you may not even be able to scale the acceleration down far enough
to make up for the new data (haven't tried it and it should roughly be fine,
but better test this first).

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

yep, we already have quirks for trackpoints anyway, adding more isn't that
hard. however - quirks are a whack-a-mole game which tends to get boring
after a while. So we need some unique identifer to know which devices need
to be handled. Maybe bump id.version, it seems to be 0 anyway for alps which
means we have plenty of numbers left before we run out.

Cheers,
   Peter


 
> > >
> > > >
> > > > 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.
> > > >
> > > > 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?
> > > > 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