linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>,
	Chung-yih Wang <cywang@chromium.org>,
	linux-input <linux-input@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Henrik Rydberg <rydberg@euromail.se>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v2] input: fix BTN_TOUCH reporting in input_mt_report_pointer_emulation
Date: Wed, 29 Oct 2014 10:14:41 +1000	[thread overview]
Message-ID: <20141029001441.GA20811@jelly.redhat.com> (raw)
In-Reply-To: <20141028210706.GC7461@dtor-ws>

On Tue, Oct 28, 2014 at 02:07:06PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 28, 2014 at 04:47:56PM -0400, Benjamin Tissoires wrote:
> > Hi Chung-yih,
> > 
> > On Mon, Oct 27, 2014 at 6:08 AM, Chung-yih Wang <cywang@chromium.org> wrote:
> > >   From the definition of BTN_TOUCH, BTN_TOOL_<name> and BTN_TOUCH codes
> > > are orthogonal. BTN_TOUCH should be zero if there is no physical contact
> > > happened on device. With ABS_MT_DISTANCE information, the patch uses
> > > touch_count and finger_count to get the final reporting code for
> > > BTN_TOUCH and BTN_TOOL_<name>, respectively.
> > >
> > > Signed-off-by: Chung-yih Wang <cywang@chromium.org>
> > > ---
> > >  drivers/input/input-mt.c | 15 ++++++++++-----
> > >  1 file changed, 10 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
> > > index fbe29fc..a2ab8e3 100644
> > > --- a/drivers/input/input-mt.c
> > > +++ b/drivers/input/input-mt.c
> > > @@ -192,18 +192,21 @@ void input_mt_report_pointer_emulation(struct input_dev *dev, bool use_count)
> > >  {
> > >         struct input_mt *mt = dev->mt;
> > >         struct input_mt_slot *oldest;
> > > -       int oldid, count, i;
> > > +       int oldid, i;
> > > +       int touch_count, finger_count;
> > >
> > >         if (!mt)
> > >                 return;
> > >
> > >         oldest = NULL;
> > >         oldid = mt->trkid;
> > > -       count = 0;
> > > +       touch_count = 0;
> > > +       finger_count = 0;
> > >
> > >         for (i = 0; i < mt->num_slots; ++i) {
> > >                 struct input_mt_slot *ps = &mt->slots[i];
> > >                 int id = input_mt_get_value(ps, ABS_MT_TRACKING_ID);
> > > +               int distance = input_mt_get_value(ps, ABS_MT_DISTANCE);
> > 
> > I don't really like this statement, even if it works. Some devices do
> > not report ABS_MT_DISTANCE, and the value for them should not be
> > considered as '0' but 'undefined'.
> 
> I think it incidentally still 0 as we zero out memory we allocate.
> 
> > 
> > >
> > >                 if (id < 0)
> > >                         continue;
> > > @@ -211,12 +214,14 @@ void input_mt_report_pointer_emulation(struct input_dev *dev, bool use_count)
> > >                         oldest = ps;
> > >                         oldid = id;
> > >                 }
> > > -               count++;
> > > +               finger_count++;
> > > +               if (distance == 0)
> > 
> > I'd rather test here if ABS_MT_DISTANCE is used, and then if the value is 0.

shouldn't you test for absinfo->minimum anyway? or does the kernel guarantee
that 0 is the minimum for distance?

> > 
> > > +                       touch_count++;
> 
> I do not think we should include hovering contacts into finger_count
> either. I.e if I have one finger touching and one finger hovering we
> should be emitting BTN_TOOL_FINGER and not BTN_TOOL_DOUBLETAP.

yes, please. DOUBLETAP for hovering would trigger things like two-finger
scrolling in some clients, not ideal.

> > >         }
> > >
> > > -       input_event(dev, EV_KEY, BTN_TOUCH, count > 0);
> > > +       input_event(dev, EV_KEY, BTN_TOUCH, touch_count > 0);
> > 
> > For the record, I *think* this will not break user space. This is used
> > in the touchpad part of libinput, and does not seemed to be impacted
> > by the change.
> > Adding Peter and Hans in CC who can tell us if I am assuming right.

should be fine, we've treated BTN_TOUCH as signal that at least one touch is
down. in the wacom driver we use it for proximity info, the rest just never
had to worry about proximity, so it's most likely just unhandled.
 
Cheers,
   Peter

> > 
> > >         if (use_count)
> > > -               input_mt_report_finger_count(dev, count);
> > > +               input_mt_report_finger_count(dev, finger_count);
> > >
> > >         if (oldest) {
> > >                 int x = input_mt_get_value(oldest, ABS_MT_POSITION_X);
> > > --
> > > 2.1.2
> > >
> 
> Thanks.
> 
> -- 
> Dmitry

      reply	other threads:[~2014-10-29  0:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 13:31 [PATCH] input: fix BTN_TOUCH reporting in input_mt_report_pointer_emulation for hovering finger Chung-yih Wang
2014-10-15 11:02 ` Chung-Yih Wang (王崇懿)
2014-10-15 18:05   ` Dmitry Torokhov
2014-10-27 10:08 ` [PATCH v2] input: fix BTN_TOUCH reporting in input_mt_report_pointer_emulation Chung-yih Wang
2014-10-28 20:47   ` Benjamin Tissoires
2014-10-28 21:07     ` Dmitry Torokhov
2014-10-29  0:14       ` 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=20141029001441.GA20811@jelly.redhat.com \
    --to=peter.hutterer@who-t.net \
    --cc=benjamin.tissoires@gmail.com \
    --cc=cywang@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rydberg@euromail.se \
    /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).