Clients reading their surface position on screen

[Christopher James Halse Rogers]

On Tue, Aug 12, 2014 at 3:09 AM, Gerry Boland 
<gerry.boland at canonical.com> 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.

I don't think this has any advantage over “shove it in 
libmirclient-debug” if we additionally say “and return garbage from 
everything in libmirclient-debug if Mir isn't started with --debug”?

I'm warming to this idea :). I think it gives everything AP needs 
without too much work (although it does mean AP needs to specifically 
know about Mir) while not allowing apps to depend on information we may 
not be able to provide.

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

My primacy concern is not about malicious apps. I'm concerned about 
apps relying on data that the compositor may not be able to provide. 
It's entirely possible that there *isn't* a correct answer for “where 
is my surface on screen”, and any attempt to use such information 
will result in incorrect behaviour.

If we expose this to Qt it'll appear to work (almost) all the time 
under Unity8, apps will find some reason to depend on this working, and 
then when we - or someone else - wants to do something funky we'll find 
that we can't because it breaks clients.