linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
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: Mon, 7 Sep 2020 13:06:34 +1000	[thread overview]
Message-ID: <20200907030634.GA13082@jelly> (raw)
In-Reply-To: <20200726234229.4edf73b4@primarylaptop.localdomain>

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

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

      reply	other threads:[~2020-09-07  3:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-06  3:50 [PATCH] Input: mms114: don't report 0 pressure while still tracking contact(s) Denis 'GNUtoo' Carikli
2020-06-06 18:18 ` Dmitry Torokhov
2020-06-08  1:06   ` Peter Hutterer
2020-06-12 17:46   ` Denis 'GNUtoo' Carikli
2020-06-14 23:57     ` Peter Hutterer
2020-06-23 16:25       ` Denis 'GNUtoo' Carikli
2020-06-26  0:04         ` Peter Hutterer
2020-07-26 21:42           ` Denis 'GNUtoo' Carikli
2020-09-07  3:06             ` Peter Hutterer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200907030634.GA13082@jelly \
    --to=peter.hutterer@who-t.net \
    --cc=GNUtoo@cyberdimension.org \
    --cc=andi@etezian.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=javi.f.o@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=rydberg@bitmath.org \
    --cc=stephan@gerhold.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).