Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp205029imm; Mon, 4 Jun 2018 15:56:47 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKPEdCN14yM0wLOmRnQhkL9NDRPK6spAkwlWs7D2HybShX2IcQkgbxjZLbsK53retwUaZ0R X-Received: by 2002:a63:9a52:: with SMTP id e18-v6mr10996764pgo.188.1528153007325; Mon, 04 Jun 2018 15:56:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528153007; cv=none; d=google.com; s=arc-20160816; b=Aw84P126exJaJFulCP+ySSYvpeSjo27vq5chlNNdnLhPHLybR4W+aX2z9IIPUGFUU1 K8RXs9yoqqBqlayCGKXwgnqrLBzSTIMLrpf5UXZrqrtxWgTxj89nIAwdv4upNbWYkXrp dRneDOQXGzis+dKO4pzt2pBiuQp4sLTixGbOXqCWJCz72Dho/G1OQGw7BZhAYHNzGQoj LRNif8d34/2FvYPB5Y2Fa3y/oi+KWyjlKm4ZvTqHUMUectrOV8c8ejWk36iyRF4fFkzZ EADli3aBJabxV1S7YXIEaO5OPyRcyBYCC90mnME1F6siLbw8ARGM31Abufoy2N3TJesR OvAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=gxqXiuC6z9UfrllHnPRjmV68x0dLEwF5ETnMlX9IC5E=; b=r3bRyl3gWrYaU4Nb0HJMUlm+WZoVGWgRFCb8BdPxYuk698gVVZkGjmk0EPI/9LOJGI AXiqtx+w3/vCJNARk7KvGvPDF5IKcCu0qOJeASYStmjlAt5oYmh8HzeYKdxnlG42+nrt nPDp+2WViD3yUxI7yh+BkzG4DRlyXp22ze9xfXDu5B9HCpVlVBDboXVJywyt6+iaBLjB Inb5+DOA6GYpPTxIL/SVc6GIehLClwvtFgbo+digbpxsunJmUzqq55AsyU78fQaoAakf bX23vExDSBg4ASezk9XJusu2MFEQ+0oEotiX6oD9mgLoSddol16vqrYKZXJIob0r9tm/ eWeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u123-v6si44906653pfu.322.2018.06.04.15.56.19; Mon, 04 Jun 2018 15:56:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbeFDWzp (ORCPT + 99 others); Mon, 4 Jun 2018 18:55:45 -0400 Received: from leo.clearchain.com ([199.73.29.74]:65335 "EHLO mail.clearchain.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbeFDWzo (ORCPT ); Mon, 4 Jun 2018 18:55:44 -0400 Received: from leo.clearchain.com (localhost [127.0.0.1]) by mail.clearchain.com (8.15.2/8.15.2) with ESMTPS id w54MtfaQ069554 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Jun 2018 08:25:42 +0930 (CST) (envelope-from peter.hutterer@who-t.net) X-Authentication-Warning: leo.clearchain.com: Host localhost [127.0.0.1] claimed to be leo.clearchain.com Received: (from whot@localhost) by leo.clearchain.com (8.15.2/8.15.2/Submit) id w54MtfbF069552; Tue, 5 Jun 2018 08:25:41 +0930 (CST) (envelope-from peter.hutterer@who-t.net) X-Authentication-Warning: leo.clearchain.com: whot set sender to peter.hutterer@who-t.net using -f Date: Tue, 5 Jun 2018 08:55:39 +1000 From: Peter Hutterer To: Dmitry Torokhov Cc: Benjamin Tissoires , Jiri Kosina , Henrik Rydberg , Jason Gerecke , Dennis Kempin , Andrew de los Reyes , "open list:HID CORE LAYER" , lkml Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches Message-ID: <20180604225539.GA13447@jelly> References: <20170811004500.13740-1-dmitry.torokhov@gmail.com> <20180601184330.GD222005@dtor-ws> <20180604173339.GB164893@dtor-ws> <20180604211944.GE164893@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180604211944.GE164893@dtor-ws> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mail.clearchain.com [127.0.0.1]); Tue, 05 Jun 2018 08:25:42 +0930 (CST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 04, 2018 at 02:19:44PM -0700, Dmitry Torokhov wrote: > On Mon, Jun 04, 2018 at 10:42:31PM +0200, Benjamin Tissoires wrote: > > On Mon, Jun 4, 2018 at 7:33 PM, Dmitry Torokhov > > wrote: > > > On Mon, Jun 04, 2018 at 03:18:12PM +0200, Benjamin Tissoires wrote: > > >> On Fri, Jun 1, 2018 at 8:43 PM, Dmitry Torokhov > > >> wrote: > > >> > On Fri, Jun 01, 2018 at 04:16:09PM +0200, Benjamin Tissoires wrote: > > >> >> On Fri, Aug 11, 2017 at 2: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). > > >> >> > > >> >> 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. > > >> > > >> After further thoughts, I would consider this to be a firmware bug, > > >> and not how the firmware is supposed to be reporting palm. > > >> For the precision touchpads, the spec says that the device "should > > >> clear the confidence bit for that contact report and all subsequent > > >> reports.". And it is how the Dell device I have here reports palms. > > >> The firmware is not supposed to cut the event stream. > > >> > > >> There is a test for that: > > >> https://docs.microsoft.com/en-us/previous-versions/windows/hardware/hck/dn456905%28v%3dvs.85%29 > > >> which tells me that I am right here for PTP. > > >> > > >> The touchscreen spec is blurrier however. > > > > > > OK, that is great to know. > > > > > >> > > >> > > > >> >> > > >> >> Do you have any precise example of reports where you need that feature? > > >> > > > >> > It was observed on Pixelbooks which use Wacom digitizers IIRC. > > >> > > >> Pixelbooks + Wacom means that it was likely a touchscreen. I am right > > >> guessing the device did not went through Microsoft certification > > >> process? > > > > > > That would be correct ;) At least the firmware that is shipping with > > > Pixlebooks hasn't, I do now if anyone else sourced these Wacom parts for > > > their MSWin devices. > > > > > >> > > >> I am in favor of splitting the patch in 2. One for the generic > > >> processing of confidence bit, and one for this spurious release. For > > >> the spurious release, I'm more in favor of explicitly quirking the > > >> devices in need of such quirk. > > > > > > Hmm, I am not sure about having specific quirk. It will be hard for > > > users to accurately diagnose the issue if firmware is broken in this way > > > so we could add a new quirk for a new device. > > > > One thing we can do is keep the quirked mechanism as default in > > hid-multitouch, but remove it in hid-core. If people need the quirk, > > they can just use hid-multitouch instead (talking about the long run > > here). > > Hmm, I am confused. My patch did not touch hid-core or hid-input, only > hid-multitouch... So we are already doing what you are proposing?.. > > > > > However, I really believe this might only be required for a handful of > > devices, and probably only touchscreens. So I would be tempted to not > > make it default and see how many bug reports we have. > > Up to you but it is hard to detect for users. If just sometimes there > are stray clicks... fwiw, from my POV, if you give me MT_TOOL_PALM in the same frame as the ABS_MT_TRACKING_ID -1 I can work that into libinput to do the right thing. Not 100% whether that already works anyway but probably not. I'd prefer it being fixed in the kernel though, less work for me :) Cheers, Peter