Re: [PATCH v2 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties

[Javier Carrasco <javier.carrasco@wolfvision.net>]

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@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.
> 
> 
> 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.