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>,
	Jiri Kosina <jikos@kernel.org>
Cc: 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-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
Date: Fri, 11 Aug 2017 08:14:03 +0200	[thread overview]
Message-ID: <5528ad84-9b42-8826-abb1-1aef06876284@bitmath.org> (raw)
In-Reply-To: <20170811004500.13740-1-dmitry.torokhov@gmail.com>

Hi Dmitry,

On 08/11/2017 02:44 AM, Dmitry Torokhov wrote:

> According to Microsoft specification [1] for Precision Touchpads (and
> Touchscreens) the devices use "confidence" reports to signal accidental
> touches, or contacts that are "too large to be a finger". Instead of
> simply marking contact inactive in this case (which causes issues if
> contact was originally proper and we lost confidence in it later, as
> this results in accidental clicks, drags, etc), let's report such
> contacts as MT_TOOL_PALM and let userspace decide what to do.
> Additionally, let's report contact size for such touches as maximum
> allowed for major/minor, which should help userspace that is not yet
> aware of MT_TOOL_PALM to still perform palm rejection.
>
> An additional complication, is that some firmwares do not report
> non-confident touches as active. To cope with this we delay release of
> such contact (i.e. if contact was active we first report it as still
> active MT+TOOL_PALM and then synthesize the release event in a separate
> frame).
Changing the tool identity to signal the tool property of low confidence 
does not seem quite right to me. Using MT_TOOL_PALM forces a semantic 
distinction between tool identity and touch state, which userland seems 
unprepared for. The additional kernel state needed to make it work 
raises the question if more considerations will turn up over with time.

Why not add a property event, like BTN_TOOL_PALM, instead? In other 
words, modifying the definition of "active" as you propose, but then use 
a BTN_TOOL_PALM property to signal "s->confidence_state"? It perhaps 
creates a different oddity for applications unaware of palm, but AFAICT, 
it would not complicate the notion of touch state. Or?

Henrik

  parent reply	other threads:[~2017-08-11  6:28 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 ` Henrik Rydberg [this message]
2017-08-11  6:54   ` [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches 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
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=5528ad84-9b42-8826-abb1-1aef06876284@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

all inboxes | Powered by JetHome®