Clients reading their surface position on screen
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Jul 22 01:26:39 UTC 2014
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
> 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 ().
>> 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
>> So I'd like to open this discussion up, and see if the Mir team have
>> considered this issue and have suggestions/plans.
>> P.S. for now I've written a hack to fix AP tests with qtComp, so this is
>> not an urgent topic.
>>  https://bugs.launchpad.net/mir/+bug/1346633
More information about the Mir-devel