Clients reading their surface position on screen

Thomas Voß thomas.voss at
Wed Jul 23 06:18:01 UTC 2014

On Tue, Jul 22, 2014 at 11:11 PM, Thomi Richards
<thomi.richards at> wrote:
> Hi,
> On Tue, Jul 22, 2014 at 8:01 PM, Thomas Voß <thomas.voss at>
> wrote:
>> so reading Gerry's initial mail, it seems to me that autopilot does
>> not actually want to deal with absolute screen coordinates (and take
>> on the burden of figuring out multi-monitor, multi-dpi cases on its
>> own) but instead wants to say: Please Mr. Mir, for this surface with
>> ID id, send an event of type Y with these attributes. Where Y is most
>> likely touch events and the attributes are surface-relative
>> coordinates. With that, we can leverage the existing mir logic, while
>> keeping AP free of global knowledge.
> Actually, that's not the case at all.
> We send events through evdev. We do this so events travel through the entire
> software stack. We don't want to insert events through mir/unity8 directly.

Well, if you would only require evdev, we would be fine for Mir.
However, AP leverages a side-channel into
the underlying, whether that is abstracted by Qt or not does not
matter here. We have strong objections supporting such a generic
side-channel by means of adding local <-> global coordinate
translation functions to the Mir client API.

> Anyway, generating events isn't the problem. The problem is figuring out Qt
> widget global (screen) coordinates from within the autopilot-qt driver.
> Ideally, we'd like to ask Qt "Please Mr Qt, please translate these local
> widget coordinates to screen-space coordinates". This is what we do
> currently, and it works[1]. I'd really like to not have to deal with mir
> directly, since the autopilot-qt driver is complicated enough as it is,
> without having to deal with mir directly. We don't currently talk to X11
> directly, it'd be a shame to add this low-level code to a library that, to
> date, contains reasonably high level code.

Awesome, no need to talk X11 or Mir directly. Adjusting the Ubuntu QPA
should be the way to go here, with the additional benefit of exposing
useful testing functionality to more clients than just Autopilot.

Back to Gerry's original list of alternatives: As far as I understand
it, Unity8 already loads a testability plugin when executed in testing
That plugin might be a good place to wire up required functionality
and expose a counterpart in the Ubuntu QPA.

@Gerry: What do you think?

> RAOF Wrote:
>> So, Qt actually has a whole bunch of holes where an API just plain isn't
>> supported on all platforms but makes no mention of it. This is one of them.
>> That call also fails on Wayland compositors, for example.
>> This should be fixed in Qt by documenting that this doesn't succeed on all
>> platforms, and allowing you to check whether you're on a platform where it
>> will.
> This may, or may not all be true, but none of it helps solve the problem :)

But it does help to understand the reasons for our strong objections:
We consciously want to avoid exposing certain sorts of functionality
via the Mir client API, taking into account the X history. Exposing
global coordinate knowledge is one such area of functionality. I can
see your strive for unification from a testing tool perspective, but
it's not as easy as "just making an API work".


> I think this conversation is drifting away from the original point. Are
> there any strong objections to making the existing Qt API "just work" on
> mir?
> Cheers,
> [1] We already handle multi-monitor configurations. I'm sure some extra code
> will have to be written when we have more unusual cases to deal with (like a
> tablet plugged in to a large screen, for example), but for now, this "just
> works".

Well, I was thinking about the upcoming requirements to support
convergence use-cases here.

> --
> Thomi Richards
> thomi.richards at
> --
> Mir-devel mailing list
> Mir-devel at
> Modify settings or unsubscribe at:

More information about the Mir-devel mailing list