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
| ||
|
Date: Mon, 4 Jun 2018 11:26:58 -0700 From: Dmitry Torokhov <dmitry.torokhov@...il.com> To: Henrik Rydberg <rydberg@...math.org> Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>, Jiri Kosina <jikos@...nel.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 Mon, Jun 04, 2018 at 07:55:57PM +0200, Henrik Rydberg wrote: > Hi Dmitry, > > > > > Logically, the confidence state is a property of a contact, not a new type > > > > of contact. Trying to use it in any other way is bound to lead to confusion. > > > > > > > > Problem is that MT_TOOL_PALM has been introduced in the kernel since > > > > v4.0 (late 2015 by a736775db683 "Input: add MT_TOOL_PALM"). > > > > It's been used in the Synaptics RMI4 driver since and by hid-asus in late 2016. > > > > I can't find any other users in the current upstream tree, but those > > > > two are already making a precedent and changing the semantic is a > > > > little bit late :/ > > I am sorry I did not respond and lost track of this issue back then, but > > I disagree with Henrik here. While confidence is a property of contact, > > so is the type of contact and it can and will change throughout life of > > a contact, especially if we will continue adding new types, such as, for > > example, thumb. In this case the firmware can transition through > > finger->thumb or finger->thumb->palm or finger->palm as the nature of > > contact becomes better understood. Still it is the same contact and we > > should not attempt to signal userspace differently. > We agree that the contact should stay the same, but the fear, and I think > somewhere along the blurry history of this thread, the problem was that > userspace interpreted the property change as a new contact (lift up/double > click/etc). Finger/thumb/palm is one set of hand properties, but what about > Pen? It would be hard for an application to consider a switch from finger to > pen as the same contact, which is where the natural implementation starts to > diverge from the intention. I think the userspace has to trust our tracking ID to decide whether it is a same contact or not. The current issue is that kernel is forcing tracking ID change on tool type change, and one of the 2 patches that I posted fixed that, allowing us to keep the tracking ID for finger->palm transitions. I think it is kernel task to not signal transitions that do not make sense, such as finger->pen or palm->pen etc. > > > We could introduce the ABS_MT_CONFIDENCE (0/1 or even 0..n range), to > > complement ABS_MT_TOOL, but that would not really solve the issue with > > Wacom firmware (declaring contact non-confident and releasing it right > > away) and given MS explanation of the confidence as "contact is too big" > > MT_TOOL_PALM fits it perfectly. > Indeed, the Wacom firmware seems to need some special handling, which should > be fine by everyone. I do think it would make sense to add > ABS_MT_TOOL_TOO_BIG, or something, and use it if it exists. This would apply > also to a pen lying down on a touchpad, for instance. OK, I can see that for Pens, if we have firmware that would recognize such condition, it would be weird to report PALM. We could indeed have ABS_MT_TOOL_TOO_BIG, but on the other hand it is still a pen (as long as the hardware can recognize it as such). Maybe we'd be better off just having userspace going by contact size for pens. Peter, any suggestions here? Thanks. -- Dmitry
Powered by blists - more mailing lists