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@xxxxxxxxx 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
