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

From: "Pali Rohár" <pali.rohar@gmail.com>
To: "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>
Cc: "Leutwein Tobias (BEG/ENC1)" <Tobias.Leutwein@de.bosch.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [RFC] linux-input alps - loosing precision
Date: Fri, 17 Jan 2020 10:42:06 +0100	[thread overview]
Message-ID: <20200117094206.xu47p6ybxmsf5ne2@pali> (raw)
In-Reply-To: <988f2b799a6046af87a25c996ebbfacb@de.bosch.com>

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