Multi-monitor thoughts

Alexandros Frantzis alexandros.frantzis at canonical.com
Fri Jun 28 07:57:40 UTC 2013


On Fri, Jun 28, 2013 at 10:02:09AM +0800, Daniel van Vugt wrote:
> 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.

The driving use case for this is having multiple xmir sessions under the
system compositor, each with its own display configuration, but can also
be applied to applications that need to set the mode under the session
compositor.

I think that the per-session configuration makes more sense as a model
for the future, and the only exception to this is the system settings
app which should set the global configuration.

Most toolkits don't have mode-setting APIs, you need to use windowing
system facilities directly, so apps will need to be rewritten for Mir
anyway if the require mode-setting. If a toolkit has such an API it can
decide how it will behave: set a session specific configuration or the
global/base configuration; mir can allow both.

Note that this does not affect how X apps under XMir work.

Thanks,
Alexandros



More information about the Mir-devel mailing list