[desktop] Configuration of screens positions and geometry

Bug #1401916 reported by Sebastien Bacher on 2014-12-12
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Undecided
Unassigned
Mir
Fix Released
Undecided
Unassigned
Ubuntu UX
Medium
Matthew Paul Thomas
qtmir (Ubuntu)
Undecided
Unassigned
unity8 (Ubuntu)
Undecided
Gerry Boland

Bug Description

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

tags: added: unity8-desktop
Launchpad Janitor (janitor) wrote :

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

Changed in unity8 (Ubuntu):
status: New → Confirmed
kevin gunn (kgunn72) wrote :

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

Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
status: New → Fix Released
Changed in unity8 (Ubuntu):
assignee: nobody → Gerry Boland (gerboland)
Daniel van Vugt (vanvugt) wrote :

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

Gerry Boland (gerboland) wrote :

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) wrote :

This doesn't appear to require any design work.

no longer affects: ubuntu-ux
Sebastien Bacher (seb128) wrote :

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

description: updated
kevin gunn (kgunn72) wrote :

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) wrote :

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

Sebastien Bacher (seb128) wrote :

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

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) wrote :

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) wrote :

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) wrote :

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.

Changed in ubuntu-ux:
assignee: nobody → Vesa Rautiainen (vesar)
status: New → Triaged
importance: Undecided → Medium
tags: added: usability
summary: - Configuration of screens positions and geometry
+ [desktop] Configuration of screens positions and geometry
Albert Astals Cid (aacid) wrote :

unity8 waiting for design -> Incomplete

Changed in unity8 (Ubuntu):
status: Confirmed → Incomplete
Vesa Rautiainen (vesar) on 2015-10-16
Changed in ubuntu-ux:
assignee: Vesa Rautiainen (vesar) → Matthew Paul Thomas (mpt)
Launchpad Janitor (janitor) wrote :

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

Changed in qtmir (Ubuntu):
status: New → Confirmed
Michał Sawicz (saviq) on 2017-03-13
affects: qtmir → qtmir (Ubuntu)
Changed in qtmir (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers