Message-ID: <aa6125d9-1233-7aab-1811-29acd4ad49a5@wolfvision.net>
Date:   Thu, 27 Apr 2023 17:59:42 +0200
From:   Javier Carrasco <javier.carrasco@...fvision.net>
To:     Jeff LaBundy <jeff@...undy.com>,
        Thomas Weißschuh <thomas@...ch.de>
Cc:     linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Henrik Rydberg <rydberg@...math.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Stephen Boyd <sboyd@...nel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Uwe Kleine-g <u.kleine-koenig@...gutronix.de>,
        Bastian Hecht <hechtb@...il.com>,
        Michael Riesch <michael.riesch@...fvision.net>
Subject: Re: [RFC v1 0/4] Input: support virtual objects on touchscreens

Hi,

On 25.04.23 18:02, Jeff LaBundy wrote:
> Hi Thomas,
> 
> On Tue, Apr 25, 2023 at 05:29:39PM +0200, Thomas Weißschuh wrote:
>> Hi Javier,
>>
>> On 2023-04-25 13:50:45+0200, Javier Carrasco wrote:
>>> 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.
>>>
>>> In order to generate proper key events by overlay buttons and adjust the
>>> touch events to a clipped surface, these patches offer a documented,
>>> device-tree-based solution by means of helper functions.
>>> An implementation for a specific touchscreen driver is also included.
>>>
>>> The functions in ts-virtobj provide a simple workflow to acquire
>>> physical objects from the device tree, map them into the device driver
>>> structures as virtual objects and generate events according to
>>> the object descriptions.
>>>
>>> This solution has been tested with a JT240MHQS-E3 display, which uses
>>> the st1624 as a touchscreen and provides two overly buttons and a frame
>>> that clips its effective surface.
>>
>> There are quite a few of notebooks from Asus that feature a printed
>> numpad on their touchpad [0]. The mapping from the touch events to the
>> numpad events needs to happen in software.
> 
> That example seems a kind of fringe use-case in my opinion; I think the
> gap filled by this RFC is the case where a touchscreen has a printed
> overlay with a key that represents a fixed function.

 Exactly, this RFC addresses exactly such printed overlays.
> 
> One problem I do see here is something like libinput or multitouch taking
> hold of the input device, and swallowing the key presses because it sees
> the device as a touchscreen and is not interested in these keys.

Unfortunately I do not know libinput or multitouch and I might be
getting you wrong, but I guess the same would apply to any event
consumer that takes touchscreens as touch event producers and nothing else.

Should they not check the supported events from the device instead of
making such assumptions? This RFC adds key events defined in the device
tree and they are therefore available and published as device
capabilities. That is for example what evtest does to report the
supported events and they are then notified accordingly. Is that not the
right way to do it?

Thanks a lot for your feedback!
> 
> Therefore, my first impression is that the virtual keypad may be better
> served by registering its own input device.
> 
> Great work by the way, Javier!
> 
>>
>> Do you think your solution is general enough to also support this
>> usecase?
>>
>> The differences I see are
>> * not device-tree based
>> * touchpads instead of touchscreens
>>
>>> [..]
>>
>> [0] https://unix.stackexchange.com/q/494400
> 
> Kind regards,
> Jeff LaBundy

Powered by blists - more mailing lists