Clients reading their surface position on screen

[Daniel van Vugt]

There is a 5th option which would satisfy more (not all) of the people 
mentioned:

5. Shell mediates if a client has permission to ask for surface 
coordinates. The API is restricted by default. The API _does_not_ return 
the top-left corner of the surface. Instead it maps a local surface 
coordinate (x,y) to screen coordinates (x',y'). This way we can still 
map correct coordinates for arbitrary 3D transformations (if we want to, 
but don't need to initially).

Also a 6th option:

6. Clients can never ask for their current position but can dictate a 
required creation position. So then they already know how to map between 
their local and screen coordinates (until moved). Such an enhancement 
would also help Mir to support client-side docks and toolbars (which 
someone will ask for eventually).

And a 7th option:

7. Unity8 gets an enhancement to be able to specify position of a 
surface in a way that AP can use. So long as the initial placement is 
honoured, then AP knows how to map between local and screen coordinates 
itself. Until the surface is moved.


On 12/08/14 01:09, Gerry Boland wrote:
> Hey folks,
> this discussion fizzled out and a conclusion wasn't clear to me. I've
> taken the liberty to summarize where the discussion got so far.
>
>
> The options considered possible (1. was dismissed):
>
> 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
>
>
> Thomi prefers solution 3. Argues that as Qt exports an API (mapToGlobal)
> to do this, Mir should respect it.
>
> RAOF objects to that, saying Qt has lots of platform-specific APIs and
> they're poorly documented. mapToGlobal is one of them. Wayland does not
> support this call either.
>
> Anpok pointed out that mapToGlobal is not able accurately to encompass
> what the compositor is doing to the client's surface (it could be
> rotated or weirdly transformed, duplicated...). RAOF & Racarr agree.
>
> TVoss objects too, prefers something like option 2 where AP injects
> events into Qt or Mir, instead of closer to the hardware with evdev.
> Thomi points out that the current evdev approach found bugs in Mir's
> input handling code, so full-stack important benefits.
>
> Duflu had idea of surface_coord_to_screen_coord function available to
> the client where the compositor (which is doing the transforming) can
> return the correct screen coords to the client. But raised latency
> concern & questioned if client occluded, what should it get back? But it
> would offer most correct implementation of mapToGlobal.
>
> RAOF open to there being a non-official API for clients
> (libmirclient-debug) that AP could use, but does not want Qt's
> mapToGlobal connected to it.
>
>
> After reading the discussion, I (Gerry) have a slightly different proposal:
>
> 4. Mir let privileged clients find their surface's screen position.
>
> Shell mediates if a client has permission to ask for its surface's
> top-left corner coordinates on screen - which is probably enough for AP.
> Or we can be more correct and implement Duflu's suggestion, after
> evaluating if the overhead is acceptable.
>
> AP will need a way to tell shell: this app needs to read its position on
> screen, so shell will allow it. Else will reject the request. That could
> be a DBus call, policed by AppArmor, and shell (unity8) would not need
> to be restarted to act upon it.
>
>
>
> Personall I don't like the idea of clients being able to ask for their
> on-screen position - really there's only a couple of valid use-cases,
> which are very special. All apps don't need this.
>
> Sure the other side of the argument is "what is the harm?" - but IMO it
> could offer that tiny bit more information to help a malicious app
> misbehave - so I'd rather play it safe.
>
> Thoughts?
> -Gerry
>
>
>