apparently I never replied to this, apologies. On Sun, Jul 26, 2020 at 11:42:29PM +0200, Denis 'GNUtoo' Carikli wrote: > On Fri, 26 Jun 2020 10:04:39 +1000 > Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > > > thanks for the log. Basically - the problem is that > > ABS_MT_TOUCH_MAJOR and ABS_PRESSURE are completely unrelated on the > > device and the latter has apparently random values. 1585880999.248531 > > is an event where you go from almost max pressure to 0 without > > changing touch major. > I also tried not to touch the screen too hard, so it's normal to have > some pressure variation as well. some pressure variation is fine, but having major unchanged while pressure changes significantly is a problem. Especially with a human finger the touch size would uusally change as you increase or decrease pressure simply because the finger gets squished. > > Since pressure is more common, you'll have to expect that userspace > > may ignore major/minor and handle pressure instead where available. > > Doubly so since historically the major/minor value range has been > > completely random while pressure was at least somewhat predictable. > > In this sequence, your touch major ranges from 4-14 despite the axis > > range being 0-255. > > > > Historically, pressure has also been used as equivalent to touch > > size, so decoupling touch size and pressure is tricky anyway. > > Speaking from libinput's POV I would disable ABS_(MT_)PRESSURE in > > this device since it's not reliable to detect a touch. But then we'd > > still need a quirk in place to tell us what the possible touch major > > range could be to make sense of that number. > > I didn't understood if I needed to do something about that patch or > not. > > Here I'm mostly interested in fixing that issue for future kernels > and/or userspace input stack releases. > > Am I supposed to fix the issue in userspace? Or is the advise on > libinput a way to deal with older kernel versions? Is the quirk > meant to be in Linux or in libinput? libinput uses ABS_MT_PRESSURE with some defaults based on the pressure range unless a (libinput) quirk tells it to use the ABS_MT_TOUCH_MAJOR axis ranges. git grep for the AttrTouchSizeRange, AttrThumbSizeThreshold and AttrPalmSizeThreshold and that'll get you there. Given the recording, i'm assuming pressure is not reliable on this device so you will have to add the quirk. > I'm currently testing with GNU/Linux as it's faster, but eventually I'm > also interested in running Android with a Linux kernel that is as much > upstream as possible, so I also need to understand the API here: Is it > up to userspace to interpret if the values are somewhat valid, or is it > up to the kernel to return valid values? yes, it's up to userspace. there's some documentation in the kernel regarding the major/minor axis ranges but not a lot of devices use it that way. Hence libinput requiring a quirk for this. Not 100% what other input stacks do though. Cheers, Peter
