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. > 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? 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? Denis.
Attachment:
pgpKv0GHS454q.pgp
Description: OpenPGP digital signature
