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
