Client display configuration notification

Alexandros Frantzis alexandros.frantzis at canonical.com
Wed Sep 30 09:50:14 UTC 2015


On Wed, Sep 30, 2015 at 02:04:00PM +1000, 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.

For a bit of background, the current scheme is:

1. User changes the hardware config (e.g. adds/removes a monitor)
2. Update base config
3.1 If base config was applied before then apply the new base config
3.2 If per-session config was applied, do nothing, expect the client
    to respond to the configuration_changed event by setting a new session
    config based on the updated base config.

The reason for "do nothing" in 3.2 is to avoid applying the base
configuration before the client has applied its own new client config,
in order to avoid extra flickering.

> When the hardware configuration changes we send the new configuration to all
> clients. However, if a client has specified a different display
> configuration then we *don't* change it. The upshot is that
> mir_connection_create_display_configuration() will *not* return the
> currently active display configuration.
>
> Furthermore, we clear the session's configuration cache, so if a session
> with custom configuration loses focus and then gains focus again it will
> *not* have its previous configuration applied.
>
> This seems like confusing behaviour, which becomes even more confusing when
> the shell gets to change the default display configuration.
> 
> I'm not entirely sure what our behaviour *should* be, though I think that we
> should at least:
> 
> a) When hardware configuration changes we should verify that any session-set
> config remains valid (for example: was the only display that session had
> enabled removed?), update the session-set config, and submit that to the
> client so that create_display_configuration() will report the *actual*
> display configuration.

Sounds reasonable, and probably easy to implement (all added and removed
outputs are disabled). We just need to ensure we don't introduce any
unnecessary configuration changes so that we don't get extra flickering.

> b) Have a way for a client to revert to default display configuration.

Also reasonable, given that with (a) the client will no longer get the
base config.

Thanks,
Alexandros



More information about the Mir-devel mailing list