[desktop] Configuration of screens positions and geometry

[Sebastien Bacher]

Under unity7/xorg it's possible to configure the position of the screens and their geometry, that includes
- resolution of each screen
- rotation possible
- relative position (external on top of laptop, or on the right)
- definition of a "primary" monitor (the one containing the launcher if you decide to have that UI element only on one screen)
- etc

Under unity7 the configuration is applied on login by unity-settings-daemon using xrandr. In the new world unity8 should probably be the one setting up the configuration at start

It would be useful to have input from design as well, on what should happen when connecting an unity8 powered device to an external screen. Should it mirror by default? Do we need settings control to configure what to do, ...

[Launchpad Janitor (janitor)]

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

[kevin gunn (kgunn72)]

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

[Daniel van Vugt (vanvugt)]

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

[Daniel van Vugt (vanvugt)]

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

[Gerry Boland (gerboland)]

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.

[Matthew Paul Thomas (mpt)]

This doesn't appear to require any design work.

[Sebastien Bacher (seb128)]

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

[kevin gunn (kgunn72)]

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).

[kevin gunn (kgunn72)]

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

[Sebastien Bacher (seb128)]

@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)

[Daniel van Vugt (vanvugt)]

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

[Gerry Boland (gerboland)]

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.

[kevin gunn (kgunn72)]

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

[Daniel van Vugt (vanvugt)]

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.

[Albert Astals Cid (aacid)]

unity8 waiting for design -> Incomplete

[Launchpad Janitor (janitor)]

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