[desktop] Configuration of screens positions and geometry

Status changed to 'Confirmed' because the bug affects multiple users.

spoke to alf, who will be back in the new year, that this is actually supported in mir.

Fix Released for Mir. It was completed around 1.5 years ago :)

Also, I've seen photographic evidence that Gerry's working on this right now.

Mir does support changing the display configuration, yes. But does Mir support saving the last display configuration to disk somehow, so it is re-applied after reboot, if possible? I didn't think so anyway.

I'm also thinking that not every application should be able to customize the display configuration. Must shell export a dbus interface to the system settings app, to allow it to change the configuration? This is one of those times when I prefer the idea of a trusted client, which has access to more privileged client APIs, and can thus edit the display config itself.

This doesn't appear to require any design work.

updated description to reflect the design requirement, ideally we need to know what happen when connecting an unity8 powered device to an external screen, also what control should be available in settings

I'm going to be bold and say, i'd rather not have "privileged clients". at least to me that seems an opportunity for complexity that comes back to haunt (e.g. privileged client & shell get cross ways with each other).

I suppose there still is an open question about mir saving off display config.

@Kevin, what are "priviledge clients"? I think it would make sense for unity8 to be the one handling screen configuration changes (e.g applying the config at start, changing it in reaction to hotkeys, etc)

I think we can (and should) draw a line between display server libraries and permanent config. It doesn't exist in Mir right now so we'd have to have a very good reason to add it.

Instead, Mir does provide structures to fully describe the display config. These structures are read and written to the display server. If you wanted to save a preferred config to disk then it's a simple matter of converting that structure to some nice format and back again. Although I suggest that is not Mir's job.

Similarly, everything else you can configure in Mir has the same problem of how to store preferences permanently. I think the right answer is to push permanent storage up to the shell so that the shell can:
  (a) Provide a nice GUI to change things; and
  (b) Use it's own preferred API. Large toolkits usually provide their own:
    Qt: QSettings
    GTK: gconf/GSettings

Do we want Mir to have an ecosystem of configuration tools around it? Because this won't happen if every shell has to implement their own configuration save/restore/change system.

I have to agree with "wouldn't every shell want this" ?
why not have a helper library as suggested by RAOF
https://lists.ubuntu.com/archives/mir-devel/2015-January/001018.html

Every large toolkit already has it's own preferred config storage and API to access that. Putting a redundant implementation in Mir is not helpful. You would either end up with the old problem of many different config file formats in unrelated places accessed using unrelated APIs, or a redundant config API that real shells will never use.

The best outcome for Unity8 would be for it to have a nice GUI that talks GSettings (or whatever it prefers) directly. Such an implementation would bypass any storage features in Mir. It should not exist in Mir. If you look at the thread, most people are saying what I'm saying here:
https://lists.ubuntu.com/archives/mir-devel/2015-January/thread.html#1018

There is a compromise that might make sense however...
While libmir* should not have any feature that touches the disk or writes files, it might provide a serialization function to convert a config structure into a string (and vice versa). And a string is something that any configuration API can use; QSettings, GSettings, gconf, INI, XML. So we can make it easier for shells, without imposing any particular file structure from Mir.

unity8 waiting for design -> Incomplete

Status changed to 'Confirmed' because the bug affects multiple users.