Subject: Display configuration

From: Alan Griffiths <[email-masked]>
Date: Fri, 25 Nov 2016 10:03:41 +0000

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,

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 28 Nov 2016 09:33:00 +0800

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

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 28 Nov 2016 10:01:50 +0800

Actually there are more functions that need fixing. But essentially I 
propose we just make the header file name, type name and function names 
all consistent:

    mir_display_config.h    // currently "mir_display_configuration.h"
    mir_display_config_*()  // most of the new API uses this already
    MirDisplayConfig        // the new API uses this already

Roughly on the same topic I've just noticed we've got some function 
names in the client API now that are around 60 characters long. That's 
obviously not OK and we should be careful to avoid such verbose naming 
in future.

---

From: Andreas Pokorny <[email-masked]>
Date: Mon, 28 Nov 2016 08:48:50 +0100

Hi,

On Mon, Nov 28, 2016 at 2:33 AM, Daniel van Vugt <
[email-masked]> wrote:

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

Alan is talking about moving and sharing more of the new internal
implementation. Getting to the agreed naming is a different topic.
I do not see what problem is solved by going in the opposite direction..

regards
Andreas

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 29 Nov 2016 11:31:54 +1100

> as servers, platforms and clients can operate in the same process, it 

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 :).