mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Henrik Rydberg <rydberg@bitmath.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Jason Gerecke <killertofu@gmail.com>,
	Dennis Kempin <denniskempin@google.com>,
	Andrew de los Reyes <adlr@google.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
Date: Mon, 4 Jun 2018 19:55:57 +0200	[thread overview]
Message-ID: <994e5698-fbdf-05c8-b0b6-3df6af1b3dbc@bitmath.org> (raw)
In-Reply-To: <20180604172759.GA164893@dtor-ws>

Hi Dmitry,

>>> Logically, the confidence state is a property of a contact, not a new type
>>> of contact. Trying to use it in any other way is bound to lead to confusion.
>>>
>>> Problem is that MT_TOOL_PALM has been introduced in the kernel since
>>> v4.0 (late 2015 by a736775db683 "Input: add MT_TOOL_PALM").
>>> It's been used in the Synaptics RMI4 driver since and by hid-asus in late 2016.
>>> I can't find any other users in the current upstream tree, but those
>>> two are already making a precedent and changing the semantic is a
>>> little bit late :/
> I am sorry I did not respond and lost track of this issue back then, but
> I disagree with Henrik here. While confidence is a property of contact,
> so is the type of contact and it can and will change throughout life of
> a contact, especially if we will continue adding new types, such as, for
> example, thumb. In this case the firmware can transition through
> finger->thumb or finger->thumb->palm or finger->palm as the nature of
> contact becomes better understood. Still it is the same contact and we
> should not attempt to signal userspace differently.
We agree that the contact should stay the same, but the fear, and I 
think somewhere along the blurry history of this thread, the problem was 
that userspace interpreted the property change as a new contact (lift 
up/double click/etc). Finger/thumb/palm is one set of hand properties, 
but what about Pen? It would be hard for an application to consider a 
switch from finger to pen as the same contact, which is where the 
natural implementation starts to diverge from the intention.

> We could introduce the ABS_MT_CONFIDENCE (0/1 or even 0..n range), to
> complement ABS_MT_TOOL, but that would not really solve the issue with
> Wacom firmware (declaring contact non-confident and releasing it right
> away) and given MS explanation of the confidence as "contact is too big"
> MT_TOOL_PALM fits it perfectly.
Indeed, the Wacom firmware seems to need some special handling, which 
should be fine by everyone. I do think it would make sense to add 
ABS_MT_TOOL_TOO_BIG, or something, and use it if it exists. This would 
apply also to a pen lying down on a touchpad, for instance.

Henrik

  reply	other threads:[~2018-06-04 17:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11  0:44 Dmitry Torokhov
2017-08-11  0:45 ` [PATCH 2/2] HID: multitouch: touchscreens also use confidence reports Dmitry Torokhov
2017-08-11  6:14 ` [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches Henrik Rydberg
2017-08-11  6:54   ` Dmitry Torokhov
2017-08-11  8:29     ` Henrik Rydberg
2017-08-18  3:08       ` Peter Hutterer
2018-05-30 23:12 ` Peter Hutterer
2018-06-01  9:31   ` Benjamin Tissoires
2018-06-01 14:16 ` Benjamin Tissoires
2018-06-01 18:43   ` Dmitry Torokhov
2018-06-01 19:03     ` Henrik Rydberg
2018-06-04 12:57       ` Benjamin Tissoires
2018-06-04 17:27         ` Dmitry Torokhov
2018-06-04 17:55           ` Henrik Rydberg [this message]
2018-06-04 18:26             ` Dmitry Torokhov
2018-06-04 20:59               ` Benjamin Tissoires
2018-06-04 21:32                 ` Dmitry Torokhov
2018-06-04 22:14                   ` Benjamin Tissoires
2018-06-04 23:06                   ` Peter Hutterer
2018-06-04 23:28                     ` Dmitry Torokhov
2018-06-04 23:51                       ` Peter Hutterer
2018-06-04 23:54                         ` Dmitry Torokhov
2018-06-04 13:18     ` Benjamin Tissoires
2018-06-04 17:33       ` Dmitry Torokhov
2018-06-04 20:42         ` Benjamin Tissoires
2018-06-04 21:19           ` Dmitry Torokhov
2018-06-04 22:03             ` Benjamin Tissoires
2018-06-04 22:55             ` Peter Hutterer
2018-06-05 13:50               ` Benjamin Tissoires
2018-06-05 17:05                 ` Dmitry Torokhov

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=994e5698-fbdf-05c8-b0b6-3df6af1b3dbc@bitmath.org \
    --to=rydberg@bitmath.org \
    --cc=adlr@google.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=denniskempin@google.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jikos@kernel.org \
    --cc=killertofu@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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

Powered by JetHome