Subject: System compositors and surfaces created by nested servers

From: Alan Griffiths <[email-masked]>
Date: Mon, 15 Jun 2015 10:09:59 +0100

In extracting some sensible default behaviour from USC I've touched on
an issue (highlighted by Alexandros) that needs discussion. As some of
interested parties may not have tracked the MP I've copied it here:

> > We have always assumed one surface per system-compositor client, so it's not
> > clear what's the correct behavior if such a client creates and posts to
> > multiple surfaces. I guess the proposed approach of always focusing the
> > "default" surface is OK for now, but perhaps in the future
> on_session_ready
> > method should be extended to also provide the surface that became
> ready.
>
> What we actually have (c.f. the nested code and spinner) is one
> fullscreen surface for each output for each system-compositor client.
>

https://code.launchpad.net/~alan-griffiths/mir/msh_SystemCompositorWindowManager/+merge/261751/comments/655398
<https://code.launchpad.net/%7Ealan-griffiths/mir/msh_SystemCompositorWindowManager/+merge/261751/comments/655398>

There are actually two issues:

/1/ Will clients of system compositors server want anything other than
fullscreen surfaces? This is what the Mir code does by default, as does
Unity8 and the USC spinner. (When I checked with Gerry on IRC he didn't
foresee a need for anything else.)

/2/ How the focus should be managed for multiple surfaces. USC just uses
the "default" surface (i.e. the first) for the client and that is copied
by this MP. (This has to be wrong as only one screen is usable.)

My feeling that the answer to the first question is that our default
"window management" for a system compositor should only support
fullscreen surfaces but that we should follow up with logic for input
focus that recognises multiple screens/surfaces.

Any dissenting opinions?

---

From: Kevin Gunn <[email-masked]>
Date: Mon, 15 Jun 2015 09:38:59 -0500

Hey Alan -
For #1, I would think it's easy to conceive of use cases where you might
have a system level arbiter that might want to have, for instance, multiple
user sessions in a spread potentially.
Maybe this means that the surfaces are still full screen, but just resized
for such a view?
in which case I'd still agree with you.
Hard to say if as we split the greeter out, it might take on more shell
like nature and have non-full screen elements to it. For now, though, I
think it sounds like a reasonable limitation.

And we are just talking about limits with respect to
unity-system-compositor? emphasis on the "unity"....it's always been viewed
as something specific to unity. Now, if we're talking about building in
limitations to the host compositor of a nested config in general
(applicable to any shell/ui)...I'd want to know more. Like how hard would
we make it to then break this paradigm later?

br,kg

On Mon, Jun 15, 2015 at 4:09 AM, Alan Griffiths <
[email-masked]> wrote:

> <
> https://code.launchpad.net/%7Ealan-griffiths/mir/msh_SystemCompositorWindowManager/+merge/261751/comments/655398
> >
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 15 Jun 2015 15:49:53 +0100

On 15/06/15 15:38, Kevin Gunn wrote:
> Hey Alan - 
> For #1, I would think it's easy to conceive of use cases where you
> might have a system level arbiter that might want to have, for
> instance, multiple user sessions in a spread potentially.
> Maybe this means that the surfaces are still full screen, but just
> resized for such a view?

Yes, from the POV of the nested server its surfaces remain fullscreen
even when they are transformed by a spread by the host.

> Hard to say if as we split the greeter out, it might take on more
> shell like nature and have non-full screen elements to it. For now,
> though, I think it sounds like a reasonable limitation.
>
> unity-system-compositor? emphasis on the "unity"....it's always been
> viewed as something specific to unity. Now, if we're talking about
> building in limitations to the host compositor of a nested config in
> general (applicable to any shell/ui)...I'd want to know more. Like how
> hard would we make it to then break this paradigm later?

Code that use Mir can always provide its own WindowManager, so what
we're providing is a bunch of helpful default behaviours that we think
appropriate to a system compositor. I've stolen what I think is generic
from USC and left the "chatting" it does with the display manager as a
configuration option (I've a WIP branch for USC that proves this).

HTH
Alan

---

From: Kevin Gunn <[email-masked]>
Date: Mon, 15 Jun 2015 10:17:12 -0500

OK, makes sense, thanks for the color.
br,kg

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 17 Jun 2015 14:06:11 +1000

> foresee a need for anything else.)

There is conceivably a requirement for non-fullscreen clients to the 
system compositor: authentication dialogs. It'd be nice to take the 
polkit authentication dialog out of the user's session, for example, 
and that would want to be overlaid on top of the user's session so not 
necessarily fullscreen.

That said, this could be supported by requiring fullscreen and just 
having most of the surface transparent.

> focus that recognises multiple screens/surfaces.

I'm not sure that it makes sense to have surface-level focus for 
system-compositor clients at all. It doesn't make sense for 
user-sessions to have surface-level focus (indeed, I expect that once 
we've got the input API for it they'll listen only to raw events).

It does make sense for an authentication dialog client to get 
surface-level input events, but only because it should have at most one 
surface.

Once we've got the missing input API bits hooked up I'd be in favour of 
allowing exactly two classes of system-compositor client:
1) Shell-type clients, which get one fullscreen surface per output but 
do not get surface-level input events, and
2) privileged-dialog-type clients, which get exactly one surface placed 
wherever the system compositor thinks is best, and which gets normal 
surface input.