linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: Charles Mooney <charliemooney@google.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Henrik Rydberg <rydberg@bitmath.org>,
	Linux Input <linux-input@vger.kernel.org>
Subject: Re: Question about ABS_DISTANCE's intended usage.
Date: Tue, 23 Feb 2016 08:04:32 +1000	[thread overview]
Message-ID: <20160222220432.GB11173@jelly.redhat.com> (raw)
In-Reply-To: <CAJ34Pp70HjQsCo-pCdHXo7FmN8KXgOAT5NKFVS-13z2c_MPzPw@mail.gmail.com>

On Mon, Feb 22, 2016 at 08:35:31AM -0800, Charles Mooney wrote:
> On Sun, Feb 21, 2016 at 2:04 PM Peter Hutterer <peter.hutterer@who-t.net> wrote:
> >
> > On Thu, Feb 18, 2016 at 10:19:30AM -0800, Dmitry Torokhov wrote:
> > > On Tue, Feb 09, 2016 at 01:56:05PM -0800, Charles Mooney wrote:
> > > > Hello all,
> > > >
> > > > I'm currently working with a touchpad vendor with a new device that
> > > > supports a limited form of hover detection.  Their sensor is able to
> > > > detect the presence or absence of a finger/hand/palm hovering over the
> > > > sensor without touching it, but is unable to report any more details
> > > > about it.  This is a more limited form of hover detection than some
> > > > devices which attach a hover state to each finger they see, and can
> > > > even report x/y coordinates to hovering finger.
> > > >
> > > > Instead of using ABS_MT_DISTANCE, it appears that the correct event to
> > > > use would be ABS_DISTANCE, since the value is not tied to a specific
> > > > finger.  I would like to check with you all about how this value is
> > > > intended to be used, because it's not quite as obvious to me as I
> > > > first thought.
> > > >
> > > > We need to handle three basic states:
> > > >   1. At least one finger is touching the pad.
> > > >   2. Something is hovering, but nothing is actually touching.
> > > >   3. Nothing is touching the pad and nothing is detected hovering over it either
> > > >
> > > > It's seems clear to me that an ABS_DISTANCE of zero should indicate
> > > > state #1 and that any other legal positive value should indicate state
> > > > #2, but I'm less clear on what the best way to handle state #3 is.
> > > > Currently, I think the best strategy would be to use a value of
> > > > ABS_DISTANCE = -1 to indicate that there are no fingers seen (hovering
> > > > or otherwise), does that make sense?
> > > >
> > > > If not this, how else would you suggest that this ought to be done?
> > >
> > > As we discussed in person, I believe that reporting an "out of bounds"
> > > value for ABS_DISTANCE when we have to use single-touch mode and thus do
> > > not have a good way to invalidate a contact, is the easiest option.
> > > Alternative would be to invent another SYN event, which I'd rather not.
> > >
> > > So for devices that support hovering but can not report individual
> > > hovering contacts we should declare 0..N as ABS_DISTANCE range and report
> > > following values:
> > >
> > >  - 0 when a finger is actually touching
> > >  - 1..N for hovering fingers
> > >  - return X < 0 or X > N when no fingers are detected at all; in
> > >    practice I think we should simply report -1 in this case.
> > >
> > > Benjamin, Peter, Henrik, any concerns?
> >
> > on the touchpads that support hovering we're already using BTN_TOOL_FINGER
> > together with ABS_DISTANCE, without needing out-of-range reports.
> > BTN_TOUCH is the signal when a finger is physically touching (or ABS_PRESSURE
> > if it exists and clients care about it).
> >
> > So the sequence Charles should send is:
> >
> > 3) <nothing> :)
> > 2)
> >     EV_ABS ABS_DISTANCE <d> # for d > 0
> >     EV_KEY BTN_TOOL_FINGER 1
> >     EV_SYN SYN_REPORT 0
> > 1)
> >     EV_ABS ABS_DISTANCE 0
> >     EV_ABS ABS_X <x>
> >     EV_ABS ABS_Y <y>
> >     ...
> >     EV_KEY BTN_TOUCH 1
> >     EV_SYN SYN_REPORT 0
> > 2)
> >     EV_ABS ABS_DISTANCE <d> # for d > 0
> >     EV_KEY BTN_TOUCH 0
> >     EV_SYN SYN_REPORT 0
> > 3)
> >     EV_KEY BTN_TOOL_FINGER 0
> >     EV_SYN SYN_REPORT 0
> >
> > This should work with at least libinput, though I have to check what happens
> > when you don't send x/y on the first event. I think this would need a patch
> > in libinput, but that's doable. And it's the same sequence we also use for
> > e.g. pen tools that support hovering as well.
> >
> > Cheers,
> >    Peter
> 
> Hi Peter,
> 
> It looks like you're suggesting to use "BTN_TOOL_FINGER" as a signal
> as to weather or not the value in "ABS_DISTANCE" is valid or not.
> 
> 1. No finger detected anywhere:
>     BTN_TOOL_FINGER = 0
>     ABS_DISTANCE = n/a
> 2. Finger seen hovering but not touching:
>     BTN_TOOL_FINGER = 1
>     ABS_DISTANCE > 0
> 2. Finger touching:
>     BTN_TOOL_FINGER = 1
>     ABS_DISTANCE = 0

you should set BTN_TOUCH here. This can be done based on some magic pressure
threshold if you have pressure, otherwise just unconditionally set it
whenever distance is 0.

> 
> Am I understanding that correctly?

yes, but IMO better to think it this way: BTN_TOOL_FINGER signals whether a
finger is detected by the device. everything else is just axis information
if and when it becomes available.
likewise, BTN_TOUCH signals whether the current tool (could be something
other than finger) logically touches the surface.

Cheers,
   Peter

  reply	other threads:[~2016-02-22 22:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 21:56 Question about ABS_DISTANCE's intended usage Charles Mooney
2016-02-18 18:19 ` Dmitry Torokhov
2016-02-21 22:04   ` Peter Hutterer
2016-02-22 16:35     ` Charles Mooney
2016-02-22 22:04       ` Peter Hutterer [this message]
2016-02-23 22:02         ` Dmitry Torokhov
2016-02-23 22:39           ` Peter Hutterer
2016-02-23 23:08             ` Dmitry Torokhov
2016-02-24  4:12               ` [PATCH] Documentation: event-codes.txt: clarify we want BTN_TOOL_<name> on proximity Peter Hutterer
2016-04-06  5:09                 ` Peter Hutterer
2016-04-06 17:16                 ` Dmitry Torokhov
2016-02-29 16:16               ` Question about ABS_DISTANCE's intended usage Charles Mooney
2016-02-23 22:42           ` Henrik Rydberg

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=20160222220432.GB11173@jelly.redhat.com \
    --to=peter.hutterer@who-t.net \
    --cc=benjamin.tissoires@redhat.com \
    --cc=charliemooney@google.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=rydberg@bitmath.org \
    /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).