From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757568AbdJKNxm (ORCPT ); Wed, 11 Oct 2017 09:53:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50678 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757515AbdJKNxg (ORCPT ); Wed, 11 Oct 2017 09:53:36 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 70E27C059B6B Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=benjamin.tissoires@redhat.com Date: Wed, 11 Oct 2017 15:53:24 +0200 From: Benjamin Tissoires To: Jiri Kosina Cc: Dmitry Torokhov , Henrik Rydberg , Wei-Ning Huang , LKML , Linux Input , Peter Hutterer Subject: Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting Message-ID: <20171011135324.GI865@mail.corp.redhat.com> References: <20171010041631.22093-1-wnhuang@google.com> <20171010065740.GA22909@mars.bitmath.org> <20171011085451.GG865@mail.corp.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 11 Oct 2017 13:53:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Oct 11 2017 or thereabouts, Jiri Kosina wrote: > On Wed, 11 Oct 2017, Benjamin Tissoires wrote: > > > I am not sure if libinput even uses ABS_MT_ORIENTATION > > I don't think it does, so that should be okay. However ... I had a meeting this Peter at noon today. The summary is that libinput doesn't uses ABS_MT_ORIENTATION, and that the documentation requires actually 3 things: - 0 is Y-aligned, up ("north") - maximum should be aligned with X, pointing toward the right ("east") - negative and out of range values are allowed >>From this, we can conclude that the minimum doesn't matter, as long as it is 0 or -max, it is the same from the user space point of view. One thing that the documentation suggests is that if we report [0, max], this would indicate that out of ranges values won't be triggered, and [-max, max] would seem to indicate that the data might be negative and so out of range values would be acceptable. Anyway, no changes in any cases from userspace. > > > , but I'd go for fixing the documentation. And re-reading it, it's not > > clear that the doc tells us to have [0,90]. It mentions negative values > > and out of ranges too, so we might just as well simply clarify that we > > rather have [-90,90], with 0 being "north". > > ... I'd like the documentation fix to go in together in one go with this > patch if possible. > Sounds like a plan. Cheers, Benjamin > Thanks, > > -- > Jiri Kosina > SUSE Labs >