Multi-monitor thoughts

Robert Ancell robert.ancell at canonical.com
Mon Jul 1 04:50:48 UTC 2013


Nice work Alexandros!

This solution captures the requirements that I know of.

--Robert


On Fri, Jun 28, 2013 at 4:10 AM, Alexandros Frantzis <
alexandros.frantzis at canonical.com> wrote:

> 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
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130701/934861e7/attachment.html>


More information about the Mir-devel mailing list