Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752483AbdHKI1r (ORCPT ); Fri, 11 Aug 2017 04:27:47 -0400 Received: from mailrelay2-2.pub.mailoutpod1-cph3.one.com ([46.30.212.1]:19343 "EHLO mailrelay2-2.pub.mailoutpod1-cph3.one.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbdHKI1p (ORCPT ); Fri, 11 Aug 2017 04:27:45 -0400 X-HalOne-Cookie: 1f66a8d0b959585a514b1841cd9ab55ff55fc348 X-HalOne-ID: f1a1b6a1-7e6e-11e7-a87d-b82a72d03b9b Subject: Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches To: Dmitry Torokhov Cc: Jiri Kosina , Benjamin Tissoires , Jason Gerecke , Dennis Kempin , Andrew de los Reyes , "linux-input@vger.kernel.org" , lkml , Peter Hutterer References: <20170811004500.13740-1-dmitry.torokhov@gmail.com> <5528ad84-9b42-8826-abb1-1aef06876284@bitmath.org> From: Henrik Rydberg Message-ID: Date: Fri, 11 Aug 2017 10:29:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1499 Lines: 30 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. > 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. > 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. Henrik