linux-kernel - Re: [PATCH 1/2] HID: multitouch: report MT_TOOL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180601184330.GD222005@dtor-ws>
Date:   Fri, 1 Jun 2018 11:43:30 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Henrik Rydberg <rydberg@...math.org>,
        Jason Gerecke <killertofu@...il.com>,
        Dennis Kempin <denniskempin@...gle.com>,
        Andrew de los Reyes <adlr@...gle.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for
 non-confident touches

On Fri, Jun 01, 2018 at 04:16:09PM +0200, Benjamin Tissoires wrote:
> On Fri, Aug 11, 2017 at 2:44 AM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> 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).
> 
> I am not sure I agree with this part. The spec says that "Once a
> device has determined that a contact is unintentional, it should clear
> the confidence bit for that contact report and all subsequent
> reports."
> So in theory the spec says that if a touch has been detected as a
> palm, the flow of events should not stop (tested on the PTP of the
> Dell XPS 9360).
> 
> However, I interpret a firmware that send (confidence 1, tip switch 1)
> and then (confidence 0, tip switch 0) a simple release, and the
> confidence bit should not be relayed.

This unfortunately leads to false clicks: you start with finger, so
confidence is 1, then you transition the same touch to palm (use your
thumb and "roll" your hand until heel of it comes into contact with the
screen). The firmware reports "no-confidence" and "release" in the same
report and userspace seeing release does not pay attention to confidence
(i.e. it does exactly "simple release" logic) and this results in UI
interpreting this as a click. With splitting no-confidence
(MT_TOOL_PALM) and release event into separate frames we help userspace
to recognize that the contact should be discarded.

> 
> Do you have any precise example of reports where you need that feature?

It was observed on Pixelbooks which use Wacom digitizers IIRC.

Thanks.

-- 
Dmitry