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

From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Henrik Rydberg <rydberg@bitmath.org>,
	Andi Shyti <andi@etezian.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	linux-input@vger.kernel.org, Javi Ferrer <javi.f.o@gmail.com>
Subject: Re: [PATCH] Input: mms114: don't report 0 pressure while still tracking contact(s)
Date: Sun, 26 Jul 2020 23:42:29 +0200	[thread overview]
Message-ID: <20200726234229.4edf73b4@primarylaptop.localdomain> (raw)
In-Reply-To: <20200626000439.GA108136@koala>

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

On Fri, 26 Jun 2020 10:04:39 +1000
Peter Hutterer <peter.hutterer@who-t.net> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]