mir on mir questions :)

Alexandros Frantzis alexandros.frantzis at canonical.com
Wed Jun 12 09:32:06 UTC 2013

On Wed, Jun 12, 2013 at 11:30:30AM +0300, Eleni Maria Stea wrote:
> 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

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

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

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

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.

> 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?

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

> - 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?

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.

> 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?

See comment for (1).

> Also another question: Can I create surfaces with the current Mir
> 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.

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

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

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

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();
    return the_nested_platform();


More information about the Mir-devel mailing list