Subject: saving off display config

From: Kevin Gunn <[email-masked]>
Date: Tue, 20 Jan 2015 08:19:32 -0600

hi all -
Just catching up on some bug house cleaning & found an open question on
this bug

https://bugs.launchpad.net/mir/+bug/1401916

Is there an architectural preference for where to save off display configs
? and reasons for the preference ?

br,kg

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 20 Jan 2015 14:36:34 +0000

On 20/01/15 14:19, Kevin Gunn wrote:
> hi all - 
> Just catching up on some bug house cleaning & found an open question
> on this bug 
>
> Is there an architectural preference for where to save off display
> configs ? and reasons for the preference ?

I would think that persistence in general is outside the scope of Mir
(or at least libmirserver[1]) as different display servers might
reasonably have different ideas on if and how it should be done.

Having said that, Mir providing a default mechanism for
serialization/deserialization of the display config could make sense.

[1] I seem to remember discussing other things that would make a useful
"helper" library that were not Mir proper - maybe we should attempt to
collate them.

---

From: Alexandros Frantzis <[email-masked]>
Date: Tue, 20 Jan 2015 16:41:57 +0200

> ? and reasons for the preference ?

Hi,

I don't think Mir itself should be the one responsible for
saving/restoring display configurations. Mir should (and indeed does)
provide a mechanism for shells to react to hardware changes and set the
configuration according to their needs.

Each shell will want to make different decisions about configurations
and also save/restore any information in a shell specific manner. I
don't see a benefit in bringing Mir into the mix.

Thanks,
Alexandros

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 21 Jan 2015 09:42:28 +1100

> "helper" library that were not Mir proper - maybe we should attempt to

I think this would be an excellent candidate for a helper library. It's 
something that nearly every shell is likely to want to do, but which is 
probably not in scope for mirserver.

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 21 Jan 2015 09:35:10 +0800

Replied in the bug  :)