Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932100AbdHRDYo (ORCPT ); Thu, 17 Aug 2017 23:24:44 -0400 Received: from leo.clearchain.com ([199.73.29.74]:43318 "EHLO mail.clearchain.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753775AbdHRDYn (ORCPT ); Thu, 17 Aug 2017 23:24:43 -0400 X-Greylist: delayed 964 seconds by postgrey-1.27 at vger.kernel.org; Thu, 17 Aug 2017 23:24:43 EDT Date: Fri, 18 Aug 2017 13:08:34 +1000 From: Peter Hutterer To: Henrik Rydberg Cc: Dmitry Torokhov , Jiri Kosina , Benjamin Tissoires , Jason Gerecke , Dennis Kempin , Andrew de los Reyes , "linux-input@vger.kernel.org" , lkml Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches Message-ID: <20170818030834.GA1144@jelly> References: <20170811004500.13740-1-dmitry.torokhov@gmail.com> <5528ad84-9b42-8826-abb1-1aef06876284@bitmath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mail.clearchain.com [127.0.0.1]); Fri, 18 Aug 2017 12:44:25 +0930 (CST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2565 Lines: 52 sorry, was at a conference/travelling and I'm slowly catching up. On Fri, Aug 11, 2017 at 10:29:07AM +0200, Henrik Rydberg wrote: > 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. whether it's a property or a tool type is up for interpretation, imo neither is right or wrong. It's common enough that the tool type changes after touch down but it's equally common for the tool type to be set at start. > > 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. note that palm does not indicate max contact size, it's merely a magic property at which point the contact is not considered a normal finger anymore. It may be size related, but it's certainly doesn't imply that it's the maximum touch size and I expect this to be even less true of devices in the future. > > 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. the closest interpretation would be "contact size/shape/location indicates that it is not a finger". I don't think you can easily narrow this down further, mostly because it's often driven by the firmware and who knows what that does. I can live with an extra property as well as long as it's per-touch, but I don't have any problems with MT_TOOL_PALM. Cheers, Peter