From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A67E0C4332F for ; Thu, 21 Oct 2021 09:27:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 908B961004 for ; Thu, 21 Oct 2021 09:27:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231488AbhJUJaL (ORCPT ); Thu, 21 Oct 2021 05:30:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231342AbhJUJaH (ORCPT ); Thu, 21 Oct 2021 05:30:07 -0400 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C1E8C06161C; Thu, 21 Oct 2021 02:27:52 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id d125so28159509iof.5; Thu, 21 Oct 2021 02:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6GpVmv67zcd/KI50WQ1qQJ95/dLiNlM3ZWZOII9XIa0=; b=nzoZGl6siilugrLLcm8C58eOQDyw8c0m6120nRh/G27l43bL9bliTsLMCtm13nO7DN F3Ul/Cno9DIBOnasbCctL9dYDwATMcF2E/+sLAhwaAtYFA9Y4q1nJIDH1xOJXP0U++22 5G9O4wjchS0yVEHmEOrFJ+LCy0FYJgQhzV60lRkceQN7ShEhsBN+qF32mrhrAyf171He ZllUmty4ARWzLBK5Pm70BBA2k40uE1gMEizteXpp/b+l5XAhMbk1G+rfG+D+8NeI3nqz dvUEmp1WAHLKDafUIBjKOl+mIyBYnoRyWVkUdcXwOhrCest3Hw4ZlmdxZgU7ZV4v/RNF W9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6GpVmv67zcd/KI50WQ1qQJ95/dLiNlM3ZWZOII9XIa0=; b=a/zbTVcjkHXVYedfyGaz394uFFEpgQQtowHbNqtnY+VRhxOygeAhrqMW0NwAskGba1 +fua1XEBEUshtha24vtY5HjdWYClHGqo/YQ8kcUkuXfyhh56Bqsd9jnyBukaTCZfKPVM xHC6HBPvigNRkbG5btM0Vf5xX7Y7BN90bz0a3htjr1lWRWwilcAv3dKIC30E9nd1ykhE I49gJHEj8KbU8AOqkOCx2HW2sXDyzvS9edGtlFwigSNYM8K1t7rtfxtWOaUHNIQU38iB kfxF2ieLdRqgmXxhIjXExm0+T2NW+9b8rvNSUrerr5GSIdTavHiUzCHUIGt9ZYbHuN/b nnYQ== X-Gm-Message-State: AOAM533qh+j1sbvF6xrk9NIOYxRep2Lply0ShQTk5OmrRUjED2w1ff02 urSo3bkWTuJIx9MGH28+FY9/Qro2MmeXAKh8vgv5YWZ7xzLT0OIH X-Google-Smtp-Source: ABdhPJxN2tv7+pO/Fc3xNrPfOq8kz/NX86VjS18bPGc/nuD7U4AMmXBs3gmZ6PXuBQN2iYSd8Cx+Sf51Top+TGpApww= X-Received: by 2002:a05:6602:2599:: with SMTP id p25mr3215194ioo.90.1634808471435; Thu, 21 Oct 2021 02:27:51 -0700 (PDT) MIME-Version: 1.0 References: <20211009114313.17967-1-alistair@alistair23.me> In-Reply-To: From: Alistair Francis Date: Thu, 21 Oct 2021 19:27:25 +1000 Message-ID: Subject: Re: [PATCH v11 1/4] HID: wacom_sys: Add support for flipping the data values To: Benjamin Tissoires Cc: Dmitry Torokhov , Ping Cheng , Alistair Francis , Shawn Guo , Sascha Hauer , dl-linux-imx , Jiri Kosina , linux-input , devicetree , LKML , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 20, 2021 at 10:04 PM Benjamin Tissoires wrote: > > On Wed, Oct 20, 2021 at 1:34 PM Alistair Francis wrote: > > > > On Wed, Oct 20, 2021 at 5:40 PM Benjamin Tissoires > > wrote: > > > > > > On Wed, Oct 20, 2021 at 4:14 AM Dmitry Torokhov > > > wrote: > > > > > > > > On Wed, Oct 20, 2021 at 11:44:50AM +1000, Alistair Francis wrote: > > > > > On Wed, Oct 20, 2021 at 11:05 AM Dmitry Torokhov > > > > > wrote: > > > > > > > > > > > > On Wed, Oct 20, 2021 at 09:33:13AM +1000, Alistair Francis wrote: > > > > > > > On Tue, Oct 19, 2021 at 11:51 AM Dmitry Torokhov > > > > > > > wrote: > > > > > > > > > > > > > > > > We already have touchscreen-inverted-x/y defined in > > > > > > > > Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml, > > > > > > > > why are they not sufficient? > > > > > > > > > > > > > > The touchscreen-* properties aren't applied to HID devices though, at > > > > > > > least not that I can tell. > > > > > > > > > > > > No, they are not currently, but that does not mean we need to establish > > > > > > a new set of properties (property names) for HID case. > > > > > > > > > > I can update the names to use the existing touchscreen ones. > > > > > > > > > > Do you have a hint of where this should be implemented though? > > > > > > > > > > Right now (without "HID: wacom: Add support for the AG14 Wacom > > > > > device") the wacom touchscreen is just registered as a generic HID > > > > > device. I don't see any good place in hid-core, hid-input or > > > > > hid-generic to invert the input values for this. > > > > > > > > I think the transformation should happen in > > > > hid-multitouch.c::mt_process_slot() using helpers from > > > > include/linux/input/touchscreen.h > > > > > > > > I think the more challenging question is to how pass/attach struct > > > > touchscreen_properties * to the hid device (i expect the properties will > > > > be attached to i2c-hid device, but maybe we could create a sub-node of > > > > it and attach properties there. > > > > > > > > > > Sorry but I don't like that very much. This would mean that we have an > > > out of band information that needs to be carried over to > > > HID-generic/multitouch and having tests for it is going to be harder. > > > I would rather have userspace deal with the rotation if we do not have > > > the information from the device itself. > > > > My 2c below > > > > > > > > Foreword: I have been given a hammer, so I see nails everywhere. > > > > > > The past 3 weeks I have been working on implementing some eBPF hooks > > > in the HID subsystem. This would IMO be the best solution here: a udev > > > hwdb rule sees that there is the not-wacom PID/VID (and maybe the > > > platform or parses the OF properties if they are available in the > > > > I'm not sure we have a specific VID/PID to work with here. The VID is > > generic AFAIK, not sure about the PID though. Maybe someone from Wacom > > could confirm either way. > > It actually doesn't really matter. What matters is that there is a way > to know that this device needs to be rotated, being through DT > properties that would be exported through sysfs, or a hwdb entry that > matches on the product, the platform or something else. > > > > > > sysfs) and adds a couple of functions in the HID stack to rotate the > > > screen. The advantage is that we do not need to add a new kernel API > > > > I would say that touchscreen-inverted-x/y isn't a new API, it's > > commonly used. To me it makes sense that it's supported for all > > touchscreens. > > Well, it's new in the HID world, and this is opening the pandora box: > the patch adds only the equivalent of touchscreen-inverted-x/y, but > not touchscreen-swapped-x-y. So you can not actually rotate a screen > by 90 degrees. > > Inverting a value on an axis is easy. Swapping 2 axes is way harder in > the HID world, because you have to interpret the report descriptor > differently. > > Also, the patch adds 3 new properties: flip-tilt-x/y and flip-distance. This patch does yes, but I'm happy to just drop this to the invert touchscreen properties. > The tilt and distance would be easy, but suddenly we need to also add > pressure, and all of the other HID definitions. This is going to be > endless. It took me a while to understand Rob's point regarding > generic properties, but we are exactly entering this territory: this > is an endless chase and will never end. > > I would much rather have a device specific quirk that would be > triggered by the DT than adding generic properties like that. That works for me! A HID_QUIRK_XY_INVERT would work for me and seems useful for others in the future as well. I managed to figure out how to do this, I'll send a patch soon. > > Also, hid-multitouch is the most tested driver through the hid-tools > test suite: https://gitlab.freedesktop.org/libevdev/hid-tools > I am not sure how I can add tests for those properties in a generic > way (the creation of the "virtual DT" is going to be problematic). > > On the contrary, a device specific quirk can easily be tested without > having to mess too much with the hid subsystem. Great! Alistair > > > > > > anymore, the disadvantage is that we need userspace to "fix" the > > > kernel behaviour (so at boot, this might be an issue). > > > > That's a pain for me. I'm still stuck with the vendors userspace as I > > need their propiritory eInk driver code. It also seems like a hassle > > for different distros to handle this (compared to just in the DT). > > I understand the pain. But I am not talking about a 1 kernel cycle > release timeframe. More like 6-12 months to bring in all the pieces > together. Distributions have no issues with udev most of the time > (even those that stuck to the old pre-systemd fork), and it would not > be different than having a udev intrinsic that tags the pen with > ID_INPUT_TABLET so libinput and others can deal with it. > > Cheers, > Benjamin > > > > > Alistair > > > > > > > > I am not at the point where I can share the code as there is a lot of > > > rewriting and my last attempt is resulting in a page fault, but I'd be > > > happy to share it more once that hiccup is solved. > > > > > > Cheers, > > > Benjamin > > > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FFA1C433EF for ; Thu, 21 Oct 2021 09:32:13 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D01B760E90 for ; Thu, 21 Oct 2021 09:32:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D01B760E90 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dNWmsMgj8xPvIUqpPXyJp9WtC8ABT/GbWv7A94wACAo=; b=VQvt/EU/ZzAq/H X1KU7d2jFE0peaGi3lRSz7bmsfzkQB0QKUy8evXvr3lwceh5sruGX2mqnyJmlOkTFCAeXGm7tL1rh LCVMO+S8Ga/Jl1BEGL37yjSsGMypeRK8jacdfRxMgmA6ecegTuYQVP9qUG0km6dlt8jDGVK2RiTdd 3QyTUrD3O4SEg/UFecfxXioeW3GGvJNwn0WerZjr3aSsD8MG8p/LfrAGnsyRWB5Eqi9J/9Mhpw/tg wxv/FvroWk+2zYMWQJTPS6GWmXnMWrvFaQ5QiB9+z0HcQnqmHldbOZJ53XTaPgJawEC2e2l7r1BSN nEyiO0lIE3W6pAaJYXSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdUP3-0072FN-Nj; Thu, 21 Oct 2021 09:30:27 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdUMb-00714P-Fz for linux-arm-kernel@lists.infradead.org; Thu, 21 Oct 2021 09:27:55 +0000 Received: by mail-io1-xd34.google.com with SMTP id p142so60473iod.0 for ; Thu, 21 Oct 2021 02:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6GpVmv67zcd/KI50WQ1qQJ95/dLiNlM3ZWZOII9XIa0=; b=nzoZGl6siilugrLLcm8C58eOQDyw8c0m6120nRh/G27l43bL9bliTsLMCtm13nO7DN F3Ul/Cno9DIBOnasbCctL9dYDwATMcF2E/+sLAhwaAtYFA9Y4q1nJIDH1xOJXP0U++22 5G9O4wjchS0yVEHmEOrFJ+LCy0FYJgQhzV60lRkceQN7ShEhsBN+qF32mrhrAyf171He ZllUmty4ARWzLBK5Pm70BBA2k40uE1gMEizteXpp/b+l5XAhMbk1G+rfG+D+8NeI3nqz dvUEmp1WAHLKDafUIBjKOl+mIyBYnoRyWVkUdcXwOhrCest3Hw4ZlmdxZgU7ZV4v/RNF W9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6GpVmv67zcd/KI50WQ1qQJ95/dLiNlM3ZWZOII9XIa0=; b=mJkATkHJfaF8fjFkyZEauBKGB5PkP9DFZ9YhTYwHVUwTKw0+Bu0SuiBv0mrvQLQdTD i8UIHzfaNoSFUCpACnkzOkghTHnqbirgKS9Ra3Vgpe2bGMRbK+n0qA7J4GBZy978SGvS iVxGQPekb/zTLWSnmlqDb01ez+B++sIr/+l0Sdfzvam10RB0H3RNxh8z4US89HqQNmP7 tJiwzzWzzwWmwIdRv4lcKmWyFPGQ37ybZrogyuDatAWxPPbcUNVPplKuAgQrR0pIB+mn sncCdnKdEhit/ymbr9NipJrsK0ydWLMTr4BZnnJZjHNa0yIz0GwvLTmWg1iUxvbXiClp WE7A== X-Gm-Message-State: AOAM531zu++zl3gtNb0tvqv8rq6bgeMzrNdAJFAlI1/mQ7fnba2UkNIk UHVod1e0T7gijwvD/mQe02KLju7PZtx2W+yA3Fg= X-Google-Smtp-Source: ABdhPJxN2tv7+pO/Fc3xNrPfOq8kz/NX86VjS18bPGc/nuD7U4AMmXBs3gmZ6PXuBQN2iYSd8Cx+Sf51Top+TGpApww= X-Received: by 2002:a05:6602:2599:: with SMTP id p25mr3215194ioo.90.1634808471435; Thu, 21 Oct 2021 02:27:51 -0700 (PDT) MIME-Version: 1.0 References: <20211009114313.17967-1-alistair@alistair23.me> In-Reply-To: From: Alistair Francis Date: Thu, 21 Oct 2021 19:27:25 +1000 Message-ID: Subject: Re: [PATCH v11 1/4] HID: wacom_sys: Add support for flipping the data values To: Benjamin Tissoires Cc: Dmitry Torokhov , Ping Cheng , Alistair Francis , Shawn Guo , Sascha Hauer , dl-linux-imx , Jiri Kosina , linux-input , devicetree , LKML , linux-arm-kernel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211021_022753_615703_4793E4FE X-CRM114-Status: GOOD ( 62.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 20, 2021 at 10:04 PM Benjamin Tissoires wrote: > > On Wed, Oct 20, 2021 at 1:34 PM Alistair Francis wrote: > > > > On Wed, Oct 20, 2021 at 5:40 PM Benjamin Tissoires > > wrote: > > > > > > On Wed, Oct 20, 2021 at 4:14 AM Dmitry Torokhov > > > wrote: > > > > > > > > On Wed, Oct 20, 2021 at 11:44:50AM +1000, Alistair Francis wrote: > > > > > On Wed, Oct 20, 2021 at 11:05 AM Dmitry Torokhov > > > > > wrote: > > > > > > > > > > > > On Wed, Oct 20, 2021 at 09:33:13AM +1000, Alistair Francis wrote: > > > > > > > On Tue, Oct 19, 2021 at 11:51 AM Dmitry Torokhov > > > > > > > wrote: > > > > > > > > > > > > > > > > We already have touchscreen-inverted-x/y defined in > > > > > > > > Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml, > > > > > > > > why are they not sufficient? > > > > > > > > > > > > > > The touchscreen-* properties aren't applied to HID devices though, at > > > > > > > least not that I can tell. > > > > > > > > > > > > No, they are not currently, but that does not mean we need to establish > > > > > > a new set of properties (property names) for HID case. > > > > > > > > > > I can update the names to use the existing touchscreen ones. > > > > > > > > > > Do you have a hint of where this should be implemented though? > > > > > > > > > > Right now (without "HID: wacom: Add support for the AG14 Wacom > > > > > device") the wacom touchscreen is just registered as a generic HID > > > > > device. I don't see any good place in hid-core, hid-input or > > > > > hid-generic to invert the input values for this. > > > > > > > > I think the transformation should happen in > > > > hid-multitouch.c::mt_process_slot() using helpers from > > > > include/linux/input/touchscreen.h > > > > > > > > I think the more challenging question is to how pass/attach struct > > > > touchscreen_properties * to the hid device (i expect the properties will > > > > be attached to i2c-hid device, but maybe we could create a sub-node of > > > > it and attach properties there. > > > > > > > > > > Sorry but I don't like that very much. This would mean that we have an > > > out of band information that needs to be carried over to > > > HID-generic/multitouch and having tests for it is going to be harder. > > > I would rather have userspace deal with the rotation if we do not have > > > the information from the device itself. > > > > My 2c below > > > > > > > > Foreword: I have been given a hammer, so I see nails everywhere. > > > > > > The past 3 weeks I have been working on implementing some eBPF hooks > > > in the HID subsystem. This would IMO be the best solution here: a udev > > > hwdb rule sees that there is the not-wacom PID/VID (and maybe the > > > platform or parses the OF properties if they are available in the > > > > I'm not sure we have a specific VID/PID to work with here. The VID is > > generic AFAIK, not sure about the PID though. Maybe someone from Wacom > > could confirm either way. > > It actually doesn't really matter. What matters is that there is a way > to know that this device needs to be rotated, being through DT > properties that would be exported through sysfs, or a hwdb entry that > matches on the product, the platform or something else. > > > > > > sysfs) and adds a couple of functions in the HID stack to rotate the > > > screen. The advantage is that we do not need to add a new kernel API > > > > I would say that touchscreen-inverted-x/y isn't a new API, it's > > commonly used. To me it makes sense that it's supported for all > > touchscreens. > > Well, it's new in the HID world, and this is opening the pandora box: > the patch adds only the equivalent of touchscreen-inverted-x/y, but > not touchscreen-swapped-x-y. So you can not actually rotate a screen > by 90 degrees. > > Inverting a value on an axis is easy. Swapping 2 axes is way harder in > the HID world, because you have to interpret the report descriptor > differently. > > Also, the patch adds 3 new properties: flip-tilt-x/y and flip-distance. This patch does yes, but I'm happy to just drop this to the invert touchscreen properties. > The tilt and distance would be easy, but suddenly we need to also add > pressure, and all of the other HID definitions. This is going to be > endless. It took me a while to understand Rob's point regarding > generic properties, but we are exactly entering this territory: this > is an endless chase and will never end. > > I would much rather have a device specific quirk that would be > triggered by the DT than adding generic properties like that. That works for me! A HID_QUIRK_XY_INVERT would work for me and seems useful for others in the future as well. I managed to figure out how to do this, I'll send a patch soon. > > Also, hid-multitouch is the most tested driver through the hid-tools > test suite: https://gitlab.freedesktop.org/libevdev/hid-tools > I am not sure how I can add tests for those properties in a generic > way (the creation of the "virtual DT" is going to be problematic). > > On the contrary, a device specific quirk can easily be tested without > having to mess too much with the hid subsystem. Great! Alistair > > > > > > anymore, the disadvantage is that we need userspace to "fix" the > > > kernel behaviour (so at boot, this might be an issue). > > > > That's a pain for me. I'm still stuck with the vendors userspace as I > > need their propiritory eInk driver code. It also seems like a hassle > > for different distros to handle this (compared to just in the DT). > > I understand the pain. But I am not talking about a 1 kernel cycle > release timeframe. More like 6-12 months to bring in all the pieces > together. Distributions have no issues with udev most of the time > (even those that stuck to the old pre-systemd fork), and it would not > be different than having a udev intrinsic that tags the pen with > ID_INPUT_TABLET so libinput and others can deal with it. > > Cheers, > Benjamin > > > > > Alistair > > > > > > > > I am not at the point where I can share the code as there is a lot of > > > rewriting and my last attempt is resulting in a page fault, but I'd be > > > happy to share it more once that hiccup is solved. > > > > > > Cheers, > > > Benjamin > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel