lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 17 May 2023 11:13:39 +0200
From:   Javier Carrasco <javier.carrasco@...fvision.net>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Henrik Rydberg <rydberg@...math.org>,
        Bastian Hecht <hechtb@...il.com>,
        Michael Riesch <michael.riesch@...fvision.net>
Cc:     linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: touchscreen: add virtual-touchscreen
 and virtual-buttons properties



On 17.05.23 10:59, Krzysztof Kozlowski wrote:
> On 16/05/2023 11:03, Javier Carrasco wrote:
>> 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@...fvision.net>
>>>>> ---
>>>>
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.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.
> 
> 
> The feature describes the hardware, not driver. To understand what does
> it mean, look from hardware point of view - does it have some virtual
> area or clipped area?
> 
>>
>> 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.
> 
> But what if actual physical buttons are added there? You still would
> have clipped/virtual area, just without virtual buttons.
> 
>>
>> 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.
> 
> To me, word "virtual" suggests something which does not exist. Kind of
> something abstracted or symbolic. Opposite to "real". Here all this
> really exists. You have physical stickers on the touchscreen.
> 
> Maybe this should be then "dedicated"? or "isolated"?
> 
> Or just "overlay-area"?
> 
>>
>> 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.
> 
> Best regards,
> Krzysztof
> 
I think the word "overlay" is more precise and does not lead to any
misunderstanding, so I will rename everything to xxx-overlay and
overlay-xxx in the code and the documentation if that is ok.
virtual-buttons -> overlay-buttons
ts_virtobj_xxx()->ts_overlay_xxx()
etc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ