Display configuration

[Christopher James Halse Rogers]

On Fri, Nov 25, 2016 at 9:03 PM, Alan Griffiths 
<alan.griffiths at canonical.com> 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,

I'm ambivalent about this. Since the client-side implementation is just 
backed by the Protobuf-generated structures it's been *really* 
convenient to implement the various extra pieces of data we've needed.

I think it would be nice if we went the other way - move the *server* 
(at least the internal bits) away from an abstract 
“DisplayConfiguration” and use the concrete RPC type there.

This is obviously unacceptable for any component of Mir that 3rd party 
code needs to interact with - graphics platforms, the shell, and so on.

Hm. I guess what I'm saying is that I think it'd be good to have a 
ABI-stable *adapter* in libmircore for all the 
interfaces-with-outside-code uses that backs onto a concrete RPC type. 
I'm not ambivalent about that :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20161129/b299c3cb/attachment.html>