From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Michael Riesch <michael.riesch@wolfvision.net>,
Javier Carrasco <javier.carrasco@wolfvision.net>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Henrik Rydberg <rydberg@bitmath.org>,
Bastian Hecht <hechtb@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties
Date: Fri, 12 May 2023 09:20:03 +0200 [thread overview]
Message-ID: <cdcd5656-2c7f-23bf-d016-fff79a279ebb@linaro.org> (raw)
In-Reply-To: <eb3f40e6-a604-39f2-eb49-8b41590a65d4@wolfvision.net>
On 12/05/2023 09:08, Michael Riesch wrote:
> Hi Krzysztof,
>
>>> These buttons are actually physical i.e. printed and with a given
>>> functionality, but still part of the touchscreen as the physical device
>>> is not aware of them. Therefore they only make sense in the touchscreen
>>> context.
>>
>> So basically you still have the same touchscreen under the buttons and
>> these are not separate devices. Whether someone put a sticker on
>> touchscreen, does not really change hardware behavior and it's up to
>> system to handle this. What you are trying to do here is to create
>> virtual buttons through Devicetree and DT is not for that.
>
> I have already addressed a similar statement here:
> https://lore.kernel.org/lkml/20230504042927.GA1129520@quokka/t/#m1a93595c36535312df0061459a1da5e062de6c44
> but let me extend this comment a bit.
>
> The notion of "someone putting a sticker on touchscreen" does not really
> reflect the use case we have in mind. We are talking about devices that
> are shipped from the factory in a particular configuration, e.g.,
>
> +-----------------------+---------+
> | | power |
> | | button |
> | touchscreen +---------+
> | (behind: display) | return |
> | | button |
> +-----------------------+---------+
>
> Here, the real touchscreen is larger than the display. The display is
> behind the "touchscreen" part. Behind the buttons there are symbols
> engraved in metal or printed foils or what not. I just would like to
> make it clear that these symbols are not going to change.
>
> We believe that the engraved or printed symbols actually define the
> (expected) hardware behavior. Of course there is a virtual notion to
> that, and of course it would be possible to let the power button work as
> return button and vice versa in software. However, the user sees the
> engraved or printed symbols (which are not going to change) and expects
> the device to react appropriately.
OK, I actually missed the concept that display is not equal to the
touchscreen ("screen" actually suggests display :) ). In your case here
it sounds good, but please put some parts of this description into this
common binding. The sketch above is nice, especially if you can point
where the virtual origin x/y are. Picture is thousands words.
>
> Now if you suggest that the system (that is user space, right?) should
> handle this, then the question would be which component is supposed to
> handle the touchscreen events and react accordingly. I don't have an
> answer to that and hope I don't need to find one. But independent of
> that, a configuration file is required that defines the area of the
> virtual buttons etc. Wouldn't this be similar to the (mostly) beloved
> xorg.conf containing the definitions of input devices?
If the case was a bit different - e.g. display is everywhere - I could
easily imagine that on the device rotation you want to move
(re-position) the buttons. Or if user has some accessibility option
enabled, you want bigger buttons. Then it would be a prove that it must
be configured and managed from user-space. How, I don't know.
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-05-12 7:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 13:50 [PATCH 0/4] Input: support virtual objects on touchscreens Javier Carrasco
2023-05-10 13:50 ` [PATCH 1/4] Input: ts-virtobj - Add touchsreen virtual object handling Javier Carrasco
2023-05-10 13:50 ` [PATCH 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties Javier Carrasco
2023-05-11 9:45 ` Krzysztof Kozlowski
2023-05-11 10:28 ` Javier Carrasco
2023-05-12 6:25 ` Krzysztof Kozlowski
2023-05-12 7:08 ` Michael Riesch
2023-05-12 7:20 ` Krzysztof Kozlowski [this message]
2023-05-12 8:13 ` Michael Riesch
2023-05-10 13:50 ` [PATCH 3/4] Input: st1232 - add virtual touchscreen and buttons handling Javier Carrasco
2023-05-13 22:38 ` kernel test robot
2023-05-15 4:34 ` Javier Carrasco
2023-05-15 6:43 ` Krzysztof Kozlowski
2023-05-15 8:33 ` Javier Carrasco
2023-05-15 8:41 ` Krzysztof Kozlowski
2023-05-15 9:08 ` Javier Carrasco
2023-05-10 13:50 ` [PATCH 4/4] dt-bindings: input: touchscreen: st1232: add example with ts-virtobj Javier Carrasco
2023-05-10 14:59 ` Krzysztof Kozlowski
2023-05-11 6:26 ` Javier Carrasco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cdcd5656-2c7f-23bf-d016-fff79a279ebb@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hechtb@gmail.com \
--cc=javier.carrasco@wolfvision.net \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.riesch@wolfvision.net \
--cc=robh+dt@kernel.org \
--cc=rydberg@bitmath.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).