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@xxxxxxxxxxxxxx> >>>>> --- >>>> >>>> >>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> >>> >>> 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.
