System compositors and surfaces created by nested servers

[Christopher James Halse Rogers]

On Mon, Jun 15, 2015 at 7:09 PM, Alan Griffiths 
<alan.griffiths at canonical.com> wrote:
> 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.)

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.

> 
> 
> /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?

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.