Multi-monitor thoughts

[Daniel van Vugt]

I think we went through this in February. Yes a virtual coordinate space 
is a good idea. And it will accommodate just about anything you can put 
on top of it.

I'm a little concerned about "Each session (aka application, Mir 
connection) will optionally have a custom display configuration 
associated with it". This sounds like Mir-specific metadata that may not 
translate into anything existing toolkits use.

I think it could be dangerous to take an approach that requires all apps 
to be Mir-aware. I'm not sure, but if an app can change output 
resolutions cleanly through the toolkit or another API right now then it 
is usually done in such a way that you are changing the monitor 
resolution and not particularly associating that with your window. Your 
window just happens to be fullscreen on that monitor.

I think it's much more familiar for apps to just ask for monitor N to be 
resolution X*Y, than to define any "config" metadata. Also much more 
flexible and simpler to implement. What you're suggesting sounds like it 
requires apps to be modified, and not just the toolkits they use.


On 28/06/13 00:10, Alexandros Frantzis 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
>