Clients reading their surface position on screen

Daniel van Vugt daniel.van.vugt at canonical.com
Tue Jul 22 01:27:47 UTC 2014


"making *life* maximally simple"


On 22/07/14 09:26, Daniel van Vugt wrote:
> What we could do is map point-to-point so as to be ready for correctly
> supporting arbitrary 3D transformations of the surfaces being touched,
> but let the shell itself make the assumption that it only ever displays
> things as flat. Thus we can:
>
>     Point top_left = mir_surface_coord_to_screen_coord(0, 0);
>
> to support all future use cases, while also making like maximally simple
> for testers of 2D shells right now :)
>
>
> On 22/07/14 09:15, Daniel van Vugt wrote:
>> Sounds like a reasonable request.
>>
>> As a matter of purity Mir has tried to hide compositor information like
>> screen position from clients, which is otherwise a good idea.
>>
>> Until now we've dithered between two approaches:
>>    (a) Support arbitrary 3D transformations but only support input
>> correctly when surfaces are flat (2D).
>>    (b) Support arbitrary 3D transformations and support accurate
>> coordinate transformation for correct input even when a surface is not
>> "flat".
>>
>> I think we're more going down the road of (b) now -- anpok touched it
>> last. In that case you would get a function:
>>      Point client_coord_to_screen_coord(Point local);
>> This supports the generalised case where under transformation, a button
>> rectangle may in fact no be a rectangle on the screen.
>>
>> But it's also kind of OK if we just want to assume transformations
>> always settle back to 2D and appear flat on the screen for the sake of
>> simplified input handling.
>>
>> - Daniel
>>
>>
>> On 22/07/14 07:42, Gerry Boland wrote:
>>> Hey folks,
>>> in working on QtCompositor, I stumbled across a problem ([1]).
>>>
>>> Autopilot needs to know the position of items in an application
>>> (buttons, etc) in screen coordinates - not surface. It needs that as it
>>> generates inputs via uevent, which are defined in screen coordinates.
>>>
>>> To calculate absolute item position, it must know the position of the
>>> application surface in screen coordinates.
>>>
>>> However Mir does not give applications this information.
>>>
>>>
>>> But Autopilot has this requirement, so how can we satisfy it?
>>>
>>>
>>> Thomi and I chewed this over a bit, and the ideas we had were:
>>>
>>> 1. unity8 exposes a DBus API which
>>>       a) allows AP to ask "what are the coordinates of the surface with
>>>          PID x
>>>       b) emit signals when surface position changes
>>>     This isn't ideal, as it requires punching holes in client appArmor
>>> confinements just for testing, and would also require a lot of work in
>>> Autopilot to be able to listen to those DBus signals.
>>>
>>> 2. AP injects events directly into Qt/unity8
>>>     Requires unity8 to be in a "testing" mode. Qt would need lots of
>>> work
>>> for it to handle relative coordinates being injected.
>>>
>>> 3. Mir let the clients find their surface's screen position
>>>
>>> But I don't think the Mir team like that final idea (I'm not a fan
>>> either).
>>>
>>>
>>> So I'd like to open this discussion up, and see if the Mir team have
>>> considered this issue and have suggestions/plans.
>>>
>>> Thanks!
>>> -Gerry
>>>
>>>
>>> P.S. for now I've written a hack to fix AP tests with qtComp, so this is
>>> not an urgent topic.
>>>
>>>
>>> [1] https://bugs.launchpad.net/mir/+bug/1346633
>>>
>>>
>>>
>>
>



More information about the Mir-devel mailing list