Display configuration

Daniel van Vugt daniel.van.vugt at canonical.com
Mon Nov 28 01:33:00 UTC 2016


Indeed this is something I'm trying to make progress on and have just 
explained my plan in the comments here:

 
https://code.launchpad.net/~vanvugt/mir/mir-display-config-header/+merge/311246

It's disapproved right now but I think when people think about the 
problem a bit more that will change.

Slightly related you may be interested in:

 
https://code.launchpad.net/~vanvugt/mir/mirout-basic-commands/+merge/311372

I don't have an opinion on moving things between libraries yet. But in 
the interest of keeping things clear and simple with minimal breaks, I 
think that can be discussed separately later.

- Daniel


On 25/11/16 18:03, Alan Griffiths wrote:
> It could be that I'm confused, or it could be that we're confused. So
> I'm starting with a quick email. If need be I'll create a doc for
> discussion.
>
> The current situation is that we have multiple incompatible
> representations of the display configuration:
>
> 1. MirDisplayConfiguration and the mir_display_config_... functions.
>
> 2. MirDisplayConfig and the mir_display_configuration_... functions.
>
> 3. The mir::graphics::DisplayConfiguration interface and the various
> platform implementations.
>
> It looks as though we have started to replace 1 with 2 but haven't yet
> finished.
>
> Looking at the code it seems the various platform implementations of 3
> "just" populate similar data structures to provide the same functionality.
>
> I think there is enough commonality that a single internal
> implementation based on 2 could be used across server, platforms and
> clients. I'd go so far as to say that DisplayConfiguration is a concept
> that ought to be in libmircore (with a suitably ABI-stable API).
>
> There would be advantages to having a single representation (DRY) and,
> as servers, platforms and clients can operate in the same process, it is
> easier to use,
>
>



More information about the Mir-devel mailing list