Client display configuration notification

[Gerry Boland]

On 30/09/15 09:16, Alan Griffiths wrote:
> On 30/09/15 05:04, Christopher James Halse Rogers wrote:
>> Forked from review¹.
>>
>> I think we're currently handling display configuration events
>> incorrectly, or at least in a way that will be surprising to clients.
> 
> I totally agree that the existing behaviour is "surprising"; what isn't
> clear to me either is what behaviour would be "unsurprising".
> 
> I think the problems arise because we conflate three distinct
> configurations:
> 
> /1/ the "base configuration" as set by the server;
> /2/ the "session configuration" as set by the client itself; and,
> /3/ and the "current configuration" as set by the active session.
> 
> We do make a distinction between "hardware" and "user" options, but that
> is simplistic.
> 
> I think we should allow the client to query each of the above (unless
> /3/ is a security concern?). We also need better tracking of consistency
> and differences between the base configuration and the session
> configuration. (E.g. currently the session configuration "locks in" the
> original values from the base configuration when not set by a client
> that "doesn't care", it may be better to only hold the values explicitly
> set.)
> 



Hey
I had to write down the typical use-cases for this feature, in order to
make it clearer to me what we actually need.

== USC - Unity8 ==

1. User changes the hardware config (e.g. adds/removes a monitor)
2. Update base config in USC, notify clients (i.e. Unity8) of updated
base config
3. Unity8 respond to the configuration_changed event by setting a new
session config based on the updated base config.

This would indeed avoid flicker when USC applies policy, and then Unity8
applies policy after.



== USC - Unity8 - Display Settings (passive consumer of display config
change) ==

1. User changes the hardware config (e.g. adds/removes a monitor)
2. Update base config in USC, notify clients (i.e. Unity8) of updated
base config
3. Unity8 respond to the configuration_changed event by setting a new
session config based on the updated base config.
4. Display Settings notified of the configuration_changed event, and can
visualize current config. It should not try to automatically apply a
policy on hardware config change - that is Unity8's job.

But Display Settings will issue config changes at other times, that
Unity8 should always act upon.



== USC - Unity8 - Game/App which cares about hardware config  (active
consumer of display config change) ==

1. User changes the hardware config (e.g. adds/removes a monitor)
2. Update base config in USC, notify clients (i.e. Unity8) of updated
base config
3. Unity8 respond to the configuration_changed event by setting a new
session config based on the updated base config.
4. App notified of the configuration_changed event, and tries to set a
new session config. Unity8 must vet this config before allowing it to be
applied.
4.1 Unity8 applies the new client-designed config while app focused.
4.2 Unity8 rejects the client-designed config, decides a config itself.

Doing 4.1 while avoiding flickering requires Unity8 to know the client
will want to change the display config if hardware state changes.


One easy way is if client ever tries to change the config, server
assumes it will react to every base config change, and so wait for that.
But that's not an obvious contract when looking at the API? How to deal
with non-responsive client, we wait for its decision, then timeout? And
how does client drop that privilege, and allow server to take control again?

Also that easy way is not really compatible with the passive consumer
case above however.


I'm still processing this, so I'm avoiding stating any opinions yet. But
does anyone see any problems with my use-cases above? Or have I
forgotten anything?

/me suspecting we'll need a doc.
-G


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20151001/d13c7bbf/attachment.pgp>