Re: [PATCH] Input: mms114: don't report 0 pressure while still tracking contact(s)

On Fri, 26 Jun 2020 10:04:39 +1000
Peter Hutterer [off-list ref] 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.