Subject: mir on mir questions :)

From: Eleni Maria Stea <[email-masked]>
Date: Wed, 12 Jun 2013 11:30:30 +0300

Hello everyone!
I started working on a nested mir a couple of days ago and I have some
questions for you after today's meeting. Actually, I am looking for a
starting point because there are many things to be done and I am not
sure what's a priority and what not...

It seems that we need to:

1- Create a mir server platform
2- Create a mir buffer allocator
3- Create a mir display
4- (Maybe) create a mir client library (we shouldn't need to)

For the 1, I guess that I only have to link to the libmirclient and add
some code that connects to an existing server during the platform
initialization. That looks easy enough for the moment unless I am
missing something important! :)

My main concerns are the buffer allocation and the display.

Let's start from the display:
- It was discussed that we need to separate the display from the buffer
mechanism and Chris has done some work on that already. Do you think
that this separation is something really necessary that I should do
before things become more complicated or I could leave it as it is since
that change doesn't add/remove functionalities?
- It was also said that there are some EGL functions I will need in the
display that are not implemented in our Mir backend for EGL (correct me
if I am wrong here) So, I guess we have to implement them, before we
proceed with the display? Is there something I could do here?

Buffer allocation:
I have to use the existing buffer mechanism for each platform. If mir is
runninng nested on gbm it will use gbm buffers and if we are using
android we ll need android buffers. So there will be a small part on mir
that won't be "mir". But there won't be any obvious problems with that
decision isn't it?

Also another question: Can I create surfaces with the current Mir
backend for EGL? Will I need to do this in the display?

For the client part:
We shouldn't need any client normally, but I remember that when I was
doing the Mir on X display I finally had to create a dummy X client that
was inheriting the gbm platform to be able to use the platform_type()
function. But maybe this shouldn't be necessary in this case.

But if I leave the gbm and android platforms as they are as some people
suggested in the meeting, then I'll have a problem with CMake that won't
compile the right client when the platform is mir.
Some solutions could be:
- use a different server and client platform in cmake (instead of
MIR_PLATFORM have MIR_SERVER_PLATFORM and MIR_CLIENT_PLATFORM)
- use a dummy mir platform that inherits from gbm_platform when we are
on pc and from android_platform when on mobile and just change the
platform_type() function
But maybe there's a better way...

Those are my first questions. I still haven't done much on this task to
have some more specific and interesting ones but I'd like to hear your
thoughts on these to get a starting point (and make sure I won't make
any changes on parts that we ll have to modify anyway for example to the
display).

Thanks a lot in advance,
Eleni

---

From: Alexandros Frantzis <[email-masked]>
Date: Wed, 12 Jun 2013 12:32:06 +0300

> 1- Create a mir server platform

The nested platform will combine the NestedDisplay and the appropriate
buffer allocator, either Android or GBM. We could have a single
NestedPlatform if we can abstract the platform details in some way,
e.g., make NestedPlatform depend on and use a NestedPlatformDetails
interface. Otherwise we need separate NestedGBMPlatform and
NestedAndroidPlatform classes.

> 2- Create a mir buffer allocator

Unless I am missing something, I don't see a need for this. The
Nested*Platform should be able to use either the GBM or Android
allocator.

> 3- Create a mir display

Correct (let's call it NestedDisplay for clarity).

> 4- (Maybe) create a mir client library (we shouldn't need to)

Ideally we won't need to.

> missing something important! :)

As a first step that should be good enough. Note, however, that when
the buffer allocator enters into the picture, the Nested*Platform should
be able to provide it with all the resources it needs to work.

> that change doesn't add/remove functionalities?

I believe it should be done before. Otherwise, when you try to create
the Nested*Platform you will need to dig out and use the GBM/Android
allocators from inside the GBM/Android platform (yuck!).

> proceed with the display? Is there something I could do here?

It's actually a problem with the GL renderer and the buffer allocator,
not the display. In order to efficiently composite a surface's buffer we
need to be able to get an EGLImage for the underlying native buffer.
This is not yet supported when using the Mir Mesa EGL platform (which
the Nested* will be using).

I am not sure what the situation on Android is.

> that won't be "mir". But there won't be any obvious problems with that

See comment for (1).

> backend for EGL? Will I need to do this in the display?

You can create EGLSurfaces from MirSurfaces. You will need to do this
in the NestedDisplay, so you can make the MirSurface the current
rendering target.

> function. But maybe this shouldn't be necessary in this case.

The client only cares about GBM vs Android, so ideally nothing will
need to change there.

> But maybe there's a better way...

I think it makes sense to keep MIR_PLATFORM and always build both the
native platform (Android or GBM) and the appropriate Nested*Platform.
Both these platforms will be available in libmirserver, and users of
libmirserver will be able to choose the one they need by overriding the
the_platform() DefaultServerConfiguration method. For example:

std::shared_ptr<mg::Platform> DefaultServerConfiguration::the_platform() override
{
    return the_native_platform();
    or
    return the_nested_platform();
}

Thanks,
Alexandros

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 12 Jun 2013 12:19:59 +0100

My instinct says that the first step would be to separate out the
graphics platform specific code in the server as a separate .so and
dlload it in DefautServerConfiguration. This could mean moving some
interfaces into the "core" code (I've not checked the details).

Then start on a "nested" version of that library - which would depends
on the client library. Both libraries would be built and the config
would determine which one is used at runtime (similar to Alexandros'
last suggestion below).

---

From: Alexandros Frantzis <[email-masked]>
Date: Wed, 12 Jun 2013 19:09:36 +0300

> > sure what's a priority and what not...

Hi all,

we [1] had a discussion today about the best way to move forward. Here
is a summary of the plan:

Implement a NestedPlatform that will provide its own Display
implementation (NestedDisplay), but will internally depend on a native
platform instance to provide most of the other components (e.g., the
buffer allocator).

In order to achieve this we need to ensure that native platforms can be
created in a way that is compatible with nested functioning (e.g. the
GBM platform shouldn't try to become the DRM master in the nested case).

In each build of libmirserver, both the native platform and the
NestedPlatform will be included. Access to the these platforms will be
provided through factory functions (tentative names/parameters):

mg::create_native_platform();
mg::create_nested_platform();
mg::create_native_platform_nested(MirPlatformPackage const&);

The last function is going to be used by the NestedPlatform to create a
properly configured native platform for internal use.

As noted in a previous email, the users of libmirserver will be able to
select either the native or the nested platform at configuration time
(think system and session compositors, respectively).

Questions/comments welcome!

Thanks,
Alexandros

[1] Eleni, Alan and I

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 13 Jun 2013 07:07:51 +0010

On Wed, 12 Jun, 2013 at 7:32 PM, Alexandros Frantzis 
<[email-masked]> wrote:
…  - It was also said that there are some EGL functions I will need 
in the
> I am not sure what the situation on Android is.
For what it's worth, enabling the EGL_DRM_BUFFER_MESA target of 
eglCreateImageKHR would be the work of an hour or so, and would get you 
something workable.

Implementing NATIVE_PIXMAP_KHR shouldn't be significantly more effort, 
either.