All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Charles Mooney <charliemooney@google.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Henrik Rydberg <rydberg@bitmath.org>
Cc: Linux Input <linux-input@vger.kernel.org>
Subject: Re: Question about ABS_DISTANCE's intended usage.
Date: Thu, 18 Feb 2016 10:19:30 -0800	[thread overview]
Message-ID: <20160218181930.GA34407@dtor-ws> (raw)
In-Reply-To: <CAJ34Pp7OM7DAiA1gZqQ0dtgXZ=z6p+LEVD5aeMiYOecHCbcfLw@mail.gmail.com>

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?

Thanks.

-- 
Dmitry

  reply	other threads:[~2016-02-18 18:19 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 [this message]
2016-02-21 22:04   ` Peter Hutterer
2016-02-22 16:35     ` Charles Mooney
2016-02-22 22:04       ` Peter Hutterer
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=20160218181930.GA34407@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=charliemooney@google.com \
    --cc=linux-input@vger.kernel.org \
    --cc=peter.hutterer@who-t.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.