Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1185240imm; Tue, 5 Jun 2018 10:19:44 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK7gdR+9Demt7sGbL30H2B3Yq5EPUFqQwni9ZOcd0yI390mkn7O9anujAdW6KlVtIDTvghf X-Received: by 2002:a62:1c43:: with SMTP id c64-v6mr26240581pfc.176.1528219184491; Tue, 05 Jun 2018 10:19:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528219184; cv=none; d=google.com; s=arc-20160816; b=g7/d0CZvwz9DRAgDcvg/n7S29D1FlESqp8mtnjmZAR73CtdQrxvzJq9g/SxHoLLQME /XaNpphGKh9O1A2GO3Pu4JsvATDJysrnDCmmPghIFcL1cOun92iWFyoha/Nh/xoEosPN ooLgqEBpmXvNyzvADAAxzmxeoGsAsTE36cs6FN4ozITFOffIgTBgh5XovB6Yjo41CKvz cTwSolaWNwSls9ITeFRLz5EXrZKdOQcIIxvezOS4IX7KWfyQAVZVcAw0QCBp1JkouFtl Z/ej955B0cV6GfwJ4ynfbC1H9qqI4gU/pw5HgzhtLhyPx4eMz82jWjkPT85G6ac4ymqo rnvA== 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:dkim-signature:arc-authentication-results; bh=gD4EnmaJST2SVT+mfxyqktoEai0zy+xR9zPdfjgG80g=; b=lo2qr0zSRbVsyhqQxRBLR6cedPCwHONrXJfTSDtqdgpwNmLiR40h92OXx3XUbGvSRM MbOOYy8WUV/aZOJIp23UjVmOE3HiokYwu3tkUl83vW+NtVgY9N0CY4KobyE+S4aRwgJz ZLzIrh0bXW+Emv6YuPu2qrTHz3qrFxQP47m/g3UvOgKNkpod0r1wKlKBq1u5oWolHwMw Btw/pSeTAfRrCWkV3BnC9v9gT/NgCwGfYq6H+J7Wn/PUlxFcuZdD3wB2JmeIP7Hy5KyN 9yeYY44dc+9N+902NPYaIMx1aye8WIazDUZQnuLguC1noBlnl04O93OGqWRwLyL+t+tU 47Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IFNqmNPr; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p5-v6si46408676plk.537.2018.06.05.10.19.30; Tue, 05 Jun 2018 10:19:44 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IFNqmNPr; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753206AbeFERFP (ORCPT + 99 others); Tue, 5 Jun 2018 13:05:15 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:44071 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbeFERFI (ORCPT ); Tue, 5 Jun 2018 13:05:08 -0400 Received: by mail-pl0-f67.google.com with SMTP id z9-v6so1887446plk.11; Tue, 05 Jun 2018 10:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gD4EnmaJST2SVT+mfxyqktoEai0zy+xR9zPdfjgG80g=; b=IFNqmNPrP3uYdX3am5guE+ytYhDDUc9UZvsO8OaJaEz4/WPLyxr/y3nMnrgB6SXKtY 6GsyDBrwbU+UTKnzV471JNcZ74pnDYFtFxhA/YDmJx75JxZL+u97rz17/ccKmkgL9ubX LFgOpA/QDxI37OItZVu9jYeiDUfIH8ktBengLDZlkmk3z9dCclcqgTaGi7KLGyCDYCpn h/SN89M0HcpdyJNOSUf7XF3foOdsmccMY6kY+MnEO0KItc3s9mSVv4YOpnmUjY91zkF9 MvYNkmjeHuU6lOgpawtgqcKxRRspDjDU1mXhlXgw8sSEbey3FBLYf6Lns8L/6E0XRrmz nLJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gD4EnmaJST2SVT+mfxyqktoEai0zy+xR9zPdfjgG80g=; b=i7kkzrrop4pbC3Oi5hXA9JchwX8p3M0AYDX3rgpBGh9PUpwEzKe8Co7Y2MCGFhukwl I0ZinXCzEEgDP/5s/jaIfxqiePkwDtQJ9tj0afMD/IqZBz9RztmSRiduf0UwXTLV+UzB 56qVwX2Mb4evZKTmwO3OZLMDVGgtePWja/MR/TD6kZ4n0I3Z8t1s1+PVxOCMVjst0Vbk h+NCdo3eqrlPbX5rr12AR0uSn/bxQGx9pdp6SI4LvJHW7JtcrFLn9WEUll8lRCwOajd5 oJsuVkyZuAhuWG+stqfMN/7y8HCT9bqyIwRYuE/3IST/lwH7VVseO0h3TeN6VAf58MPZ un9A== X-Gm-Message-State: ALKqPwdFcuIWrKh3P54RpalZjq9dg/AvJ0Xy+zJ5O0FtebVYMKvLVb92 xmox3Be8fGEt1WiVqf+mP/w= X-Received: by 2002:a17:902:3303:: with SMTP id a3-v6mr27309608plc.209.1528218307168; Tue, 05 Jun 2018 10:05:07 -0700 (PDT) Received: from dtor-ws ([2620:0:1000:1511:8de6:27a8:ed13:2ef5]) by smtp.gmail.com with ESMTPSA id o70-v6sm83379228pfo.49.2018.06.05.10.05.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Jun 2018 10:05:05 -0700 (PDT) Date: Tue, 5 Jun 2018 10:05:03 -0700 From: Dmitry Torokhov To: Benjamin Tissoires Cc: Peter Hutterer , 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: <20180605170503.GC202428@dtor-ws> References: <20170811004500.13740-1-dmitry.torokhov@gmail.com> <20180601184330.GD222005@dtor-ws> <20180604173339.GB164893@dtor-ws> <20180604211944.GE164893@dtor-ws> <20180604225539.GA13447@jelly> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 03:50:15PM +0200, Benjamin Tissoires wrote: > On Tue, Jun 5, 2018 at 12:55 AM, Peter Hutterer > wrote: > > 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. > > This would be a one line change in the kernel, so you got my attention :) Umm, there are other input stacks beyond libinput. > > > Not 100% whether that already works anyway but probably not. I'd prefer it > > being fixed in the kernel though, less work for me :) > > What do you mean by "fixed"? > Is it incorrect to send a tool while tracking ID is set to -1? > From what I read on multi-touch-protocol.rst this shouldn't be > violating the protocol, and this would save quite a mess in the kernel > in which we need to add an artificial event in the queue for the > release. Well, we say "A non-negative tracking id is interpreted as a contact, and the value -1 denotes an unused slot." Unless you are a protocol lawyer, the most sensible way of interpreting it is to ignore whatever is transmitted for the slot once receiving tracking ID of -1. Given that this is particular firmware quirk that sends confidence and release in the same report, I'd prefer if we had a quirk in driver rather than pushing the responsibility to userspace. Thanks. -- Dmitry