linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrik Rydberg <rydberg@bitmath.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Jason Gerecke <killertofu@gmail.com>,
	Dennis Kempin <denniskempin@google.com>,
	Andrew de los Reyes <adlr@google.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Peter Hutterer <peter.hutterer@who-t.net>
Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
Date: Fri, 11 Aug 2017 10:29:07 +0200	[thread overview]
Message-ID: <c1a6ca9c-5f4d-cc9e-fc36-71d7d6aff640@bitmath.org> (raw)
In-Reply-To: <CAKdAkRRRo-Xz5O7+gVQcAH5=PnEgwhDx4eYvyBZe7Qbves21kg@mail.gmail.com>

Hi Dmitry,

> The meaning of confidence is literally "contact is too large to be a
> finger", so it is not touch state, but really tool identity. We do
> allow tool identity to change over time.
What I am arguing is rather that since "palm" is a property, just like 
contact size, there should be no need to confuse that property with the 
touch state, which is, as you state, what happens in userland when the 
tool type is modified. Using a different event for the palm property 
ought to remove that confusion.

> The additional state is simply because we have never updated the tool
> type on release events and userspace is not expecting it and is likely
> to ignore any data in the slot that is accompanied with
> ABS_TRACKING_ID == -1. So we synthesize an extra event to have
> distinct tool change and release.

We update all other properties of a contact freely at release, so logically there is no good reason to treat palm, the binary version of max contact size, differently.
  

> Mostly because with BTN_TOOL_PALM we are not able to decide which
> contact is turning into palm. Also, other drivers (RMI) use
> MT_TOOL_PALM and I would like to report palm state in unified way.
Precedent certainly matters, but in this case, I think the modification 
promises problems down the road. I would rather suggest to add a new 
binary palm property, with the precise meaning "contact size = max 
contact size", and take it from there. I dont mind writing a patch for 
it if you agree.

Henrik

  reply	other threads:[~2017-08-11  8:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11  0:44 [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches 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 [this message]
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
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=c1a6ca9c-5f4d-cc9e-fc36-71d7d6aff640@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 \
    --cc=peter.hutterer@who-t.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).