<div dir="ltr"><div><div>Nice work Alexandros! </div>This solution captures the requirements that I know of. </div>--Robert </div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jun 28, 2013 at 4:10 AM, Alexandros Frantzis <<a href="mailto:alexandros.frantzis@canonical.com" target="_blank">alexandros.frantzis@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, there are two related but slightly different aspects of multi-monitor handling. The first is reacting to HW configuration changes (e.g. user plugs in/out a monitor). The second is reacting to configuration change requests from clients. It's a complex situation, and I am trying to find some model that will elegantly and simply accommodate both of these aspects. Here are my thoughts so far... The display server works with a virtual coordinate space, which is used for both display and input. Outputs are placed in rectangles in this coordinate space. A display configuration is a particular placement of the outputs in the coordinate space (of course, not placing an output is a valid placement) with valid sizes for each output (corresponding to a supported mode). The display server will have a base display configuration. Each session (aka application, Mir connection) will optionally have a custom display configuration associated with it. Having such a configuration means that the session has special modesetting needs, and that this configuration will be applied when the session is focused (whatever this means in each case), and reverted (i.e. the base configuration will be reapplied) when we focus a normal session. Here is how this would work in some interesting scenarios: Scenario 1: Two XMir sessions ----------------------------- We are in the greeter, with the base configuration applied. XMir session 1 starts up, gets the base display configuration, sends back a changed configuration and creates/changes its surfaces to match the configuration. Mir applies the new config since XMir 1 has the focus. We switch away from XMir 1 to the greeter, therefore reverting to the base configuration. XMir session 2 starts up, gets the base display configuration, sends back a changed configuration and changes its surfaces to match the configuration. Mir applies the new config since XMir 2 has the focus. Now, as we switch between XMir 1 and XMir 2 their respective custom configurations are applied. Scenario 2: Two XMir sessions, new monitor plugged/removed ---------------------------------------------------------- XMir 1 is active, a new monitor is plugged. Mir detects the change and changes its base configuration (without applying it, since a session with a custom config has the focus). It then notifies all sessions (or perhaps only those who already have a special config). XMir 1 gets the new (base) configuration, decides what it needs, sends a new config back and changes its surfaces to match. Since XMir 1 is the focused session, Mir applies the new configuration. XMir 2 gets the new (base) configuration, decides what it needs, sends new config back, changes its surfaces to match. The XMir 2 configuration is not applied since XMir 2 is not focused. Scenario 3: XMir requests new config (e.g. an XRandR request) ------------------------------------------------------------- XMir sends a new config to Mir, and changes its surfaces to match. Mir gets and applies the new configuration (since presumably XMir is focused). Scenario 4: Mir session/app messes up its custom display configuration ---------------------------------------------------------------------- No problem. When the session/app loses focus (or gets killed) the base configuration will be applied. Scenario 5: Native Mir app wants to become fullscreen in one of the connected screens ------------------------------------------------------------------- The app gets the base display configuration, creates or changes its surfaces to become fullscreen. Scenario 6: Native Mir app wants to become fullscreen in one of the connected screens *and* wants to have a different resolution there. ------------------------------------------------------------------- The app gets the base display configuration, changes what it needs (e.g. changes modes and position in virtual space in one of the connected screens) and changes surfaces to match. This is the same as the XMir cases discussed above. Will we allow all apps to change the modes? Note that for these scenarios to work, we need to allow clients to make a surface fullscreen for a specific output (they can get output ids from the configuration). Thanks, Alexandros -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a> </blockquote></div> </div>