From: Javier Carrasco <javier.carrasco@wolfvision.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
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>,
Michael Riesch <michael.riesch@wolfvision.net>
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties
Date: Tue, 16 May 2023 11:03:48 +0200 [thread overview]
Message-ID: <d32e46aa-af50-ad60-7679-5c235487039e@wolfvision.net> (raw)
In-Reply-To: <99e39fb6-26e0-eb9a-3c07-e07d1fa4122c@linaro.org>
On 16.05.23 10:13, Krzysztof Kozlowski wrote:
> On 16/05/2023 10:10, Krzysztof Kozlowski wrote:
>> On 15/05/2023 17:00, Javier Carrasco wrote:
>>> The virtual-touchscreen object defines an area within the touchscreen
>>> where touch events are reported and their coordinates get converted to
>>> the virtual origin. This object avoids getting events from areas that
>>> are physically hidden by overlay frames.
>>>
>>> For touchscreens where overlay buttons on the touchscreen surface are
>>> provided, the virtual-buttons object contains a node for every button
>>> and the key event that should be reported when pressed.
>>>
>>> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
>>> ---
>>
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Apologies, second thoughts - why calling all this binding and properties
> "virtual"? That's the word which immediately raises questions, because
> bindings are only for real things, not virtual.
>
> Touchscreen is just clipped, not virtual, so maybe "clipped-area"
> instead of virtual-touchscreen? Buttons are real, so maybe just "buttons"?
>
> Best regards,
> Krzysztof
>
I guess it is a matter of perspective. For a user the buttons and the
clipped area are 100% real, but for a driver developer they are virtual
in the sense that there is not an "active" hardware behind apart from
the original touchscreen.
I just wanted to avoid misunderstandings when implementing this feature
for other drivers. One might wonder if the touchscreen now has
mechanical keys attached to it. With the "virtual-" prefix it is clear
that the objects are not additional pieces of hardware or extensions of
the touchscreen functionality.
For the virtual-touchscreen your point is stronger because there is
indeed a real touchscreen hardware no matter the area you define, but my
approach was keeping homogeneous names for the different objects in case
some new ones might appear in the future: every object that gets on top
of the touchscreen area is virtual, so add a new object type and name it
virtual-xxx.
I have nothing against about doing some renaming and I will do it if it
is required, but with the documentation I think it is now more clear
what everything means and in the end it might make more sense for the
drivers so they can differentiate between real and virtual devices.
next prev parent reply other threads:[~2023-05-16 9:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 15:00 [PATCH v2 0/4] Input: support virtual objects on touchscreens Javier Carrasco
2023-05-15 15:00 ` [PATCH v2 1/4] Input: ts-virtobj - Add touchscreen virtual object handling Javier Carrasco
2023-05-15 15:00 ` [PATCH v2 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties Javier Carrasco
2023-05-16 8:10 ` Krzysztof Kozlowski
2023-05-16 8:13 ` Krzysztof Kozlowski
2023-05-16 9:03 ` Javier Carrasco [this message]
2023-05-17 8:59 ` Krzysztof Kozlowski
2023-05-17 9:13 ` Javier Carrasco
2023-05-15 15:01 ` [PATCH v2 3/4] Input: st1232 - add virtual touchscreen and buttons handling Javier Carrasco
2023-05-15 15:01 ` [PATCH v2 4/4] dt-bindings: input: touchscreen: st1232: add example with ts-virtobj 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=d32e46aa-af50-ad60-7679-5c235487039e@wolfvision.net \
--to=javier.carrasco@wolfvision.net \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hechtb@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@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
all inboxes | Powered by JetHome®