Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 27 Apr 2023 12:45:25 -0500
From:   Jeff LaBundy <jeff@labundy.com>
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Michael Riesch <michael.riesch@wolfvision.net>,
        Javier Carrasco <javier.carrasco@wolfvision.net>,
        phone-devel@vger.kernel.org, linux-input@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Henrik Rydberg <rydberg@bitmath.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Hans Verkuil <hverkuil-cisco@xs4all.nl>,
        Stephen Boyd <sboyd@kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Uwe Kleine-g <u.kleine-koenig@pengutronix.de>,
        Bastian Hecht <hechtb@gmail.com>
Subject: Re: [RFC v1 0/4] Input: support virtual objects on touchscreens
Message-ID: <ZEq0taaQFT1znDN6@nixie71>
References: <20230425115049.870003-1-javier.carrasco@wolfvision.net>
 <ZEpWrWpzkI9kNTkr@duo.ucw.cz>
 <de87d6ae-3449-5581-3e17-4aae72e8197a@wolfvision.net>
 <ZEp1Z08/CQ+waw8+@duo.ucw.cz>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZEp1Z08/CQ+waw8+@duo.ucw.cz>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jEI7hytQpfc9+O8ZZ6Si6bu1+m8GTH0S9WppGU3NT4mg83jdY50irry4+ZWb?=
 =?us-ascii?Q?GwYqDjrRoDMhwz/g5KJIuXX5B1xzZkdd/hd36w7iVL7tG1Oz/9xygvFBuJw6?=
 =?us-ascii?Q?ap2rVszEb4+3+i8xr/4ZbIeg53aDc0S3ne/IuN57UKHCk72bXJUN/zHIcFZ6?=
 =?us-ascii?Q?SuE9oEOxIVc/0w33uJPaluB1Cez63PVQR8xdCiuGo2TkRA+VtHx1tVsErJMR?=
 =?us-ascii?Q?eA0RqgCICO5O2haiwTFUmp75a9MYJozUnvFEyZckWJxoaO2NgNRsviR/JEWn?=
 =?us-ascii?Q?XAeFaYIpxvWy7lT0dQy7r7N44JyPtlQeqF9HCReZyrbnrkfkYwlUb+zPPmcn?=
 =?us-ascii?Q?9GoYI6+coNkYy6eo9VN0bxwLjryJ0HyvTmgBIc0h2JlgfhTJahZE5YaxlDyT?=
 =?us-ascii?Q?Hr72pWPg9YfA3TtJq1Jixh6ppB6l6mOJNnw5aq8GtdM/+CrbtFG5RDQaAFz6?=
 =?us-ascii?Q?+hTz4ApGuKxF2/uoX3Ez4kWQMjy6NihkAQELbBqxn/eVYcNWKXYabEo0Z+RB?=
 =?us-ascii?Q?ni9+Dg6+KgL/xrIiJUr5HZmaH3DMFnA1PZa1HVwZAfTI9vd7flx6llk3EI8n?=
 =?us-ascii?Q?iCHhVh//rwEwUWj8zvn0MPpbIe+GHGvHNgiyPfvBiIBVAjcKolLhrSuRXWqt?=
 =?us-ascii?Q?5J7w+4Td8n07dYIvo3LK4rDoi0DEUw9uGb3coNOXIvdFamj1xKAW1GvDjWX9?=
 =?us-ascii?Q?3UWk8WTWUEV0zmokOIGDrQre8GxctsOQbKQWRTZHHDErWD9xLgLCpyzHmtqU?=
 =?us-ascii?Q?Z0b/80W7LbUFmuP1CYx1A6VmpVPZKRlBKlTIn6P3YNQtUrMOVD1dAK6uNa6n?=
 =?us-ascii?Q?Fj7EB+hG3pjgcTmOcZkqpz+pBL5xDIK6VSidu1ATYs02C86eQZKji89S0BMl?=
 =?us-ascii?Q?7ZNIr5Gn9RwKsmJ4KuP4kiwZw/adyLnUErH8dH+a/tlCvhJt8oX6g+sNuZc9?=
 =?us-ascii?Q?3lxjoAVz+zxPozTnfYppO/QE78qiJr9dyiucXMQI0Gml+WALXxzDpE7mgzSA?=
 =?us-ascii?Q?WRD9WPPpyZ62BUlc4xhkHAUWXwE8DfOoja+qekpKaUamcB5t+QOwtFrnvwl7?=
 =?us-ascii?Q?lWIbkcaeTo3CLW2jmmQcBXIfQuBbpH0kwAlc7m7u1i6BUAlE5H9CaGW9yPtR?=
 =?us-ascii?Q?65XewM5pLe8YBz4+BsCnZ8jlOQiOs02TgoSIAOv+gGxzSJjg42Z6pf2TyE4b?=
 =?us-ascii?Q?xuTPZZcHye8pGSY4GxcJcb9Rd9AG39c+u3xrAdktk4HPm+BAT0hVfwlgPZVB?=
 =?us-ascii?Q?+JmKIdnwmS2d0pK0zf3JMrhaJuPd2sBmcuEVmBna0gpLt0TdhURKVI62DtAm?=
 =?us-ascii?Q?vEKOqTcQoRvcknl7zfJAiVuejTeg4WHBJ++iCKALK0XBbPuBJv9VDIuP1s8i?=
 =?us-ascii?Q?5HyfQGrO21wrkWvhUlFIrvw3HPn2gxPYzqKmSd8p7yBJIYcTyXZzqARnRmG9?=
 =?us-ascii?Q?x4aE4B9yOIhqTaM1x69uQ9pIZkA77wrntroqwjNqRR0D/HOaKYxVeEx9WpIJ?=
 =?us-ascii?Q?VIeZDYD8hZZ8CDw+YkBBWSKx724S6qg34Qo98mf+B9Re4vJoKcGPTw7KSmxp?=
 =?us-ascii?Q?QDnGDs4gBhO1ag31PEqYCitfhKmzOgdwctWRWqkF?=
X-OriginatorOrg: labundy.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e142c4de-3297-42d2-78ba-08db4747324c
X-MS-Exchange-CrossTenant-AuthSource: SN4PR0801MB3774.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2023 17:45:31.7129
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 00b69d09-acab-4585-aca7-8fb7c6323e6f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QYXcA31vRgyOOx1mO8t2HdXIJEnSuMTKEdBSOi5RsL2ceII6ueLOtjmOjHQqKMMSZt2XdBH7+iPaAzz7fBM/2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR08MB7930
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Pavel,

On Thu, Apr 27, 2023 at 03:15:19PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > 
> > >> Some touchscreens are shipped with a physical layer on top of them where
> > >> a number of buttons and a resized touchscreen surface might be
> > >> available.
> > > 
> > > Yes, it is quite comon, for example Motorola Droid 4 has 4 virtual
> > > buttons below touchscreen.
> > 
> > Are those buttons configurable in some way? Or do they have a fixed purpose?
> 
> Fixed.
> 
> > How does Android handle those buttons, BTW?
> 
> No idea.
> 
> > > One question is if this should be handled inside the kernel. It will
> > > make it compatible with existing software, but it will also reduce
> > > flexibility.

That's a great question; I think there are arguments for both.

On one hand, we generally want the kernel to be responsible for nothing more
than handing off the raw coordinate and touch information to user space. Any
further translation of that represents policy which would not belong here.

On the other hand, the notion of what buttons exist and where is very much a
hardware statement for the use-case targeted by this RFC. It would be ideal
if both the kernel and user space did not need to know information about the
same piece of hardware. So I think it is OK for the driver to give some help
by doing some of its own interpretation, much like some hardware-accelerated
solutions already do.

While there are obviously exceptions in either case, I don't see any reason
to prohibit having a simple option like this in the kernel, especially since
it doesn't preclude having something in user space for more advanced cases.

> > 
> > I would say that it should be described in device tree if the purpose is
> > fixed. For example, if there is no display behind the touch screen at a
> > certain point but a printed sheet (e.g., with a home or return symbol)
> > then it is clear that this button is not going to change. In such a case
> > I doubt that flexibility is required.
> 
> I agree it should be in the device tree.
> 
> AFAICT hardware can do drags between the buttons, and drag between the
> buttons and touchscreen. Turning it into buttons prevents that.
> 
> Plus, real buttons can do simultaneous presses on all of them,
> touchscreens will have problems with that.

I interpreted the RFC and its example to accommodate multitouch support, so
I don't see any problem here unless the vendor built such a module without
a multitouch panel which would not make sense. Let me know in case I have
misunderstood the concern.

> 
> Best regards,
> 								Pavel
> -- 
> People of Russia, stop Putin before his war on Ukraine escalates.

Kind regards,
Jeff LaBundy