mir on mir questions :)
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
> 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
> 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
> 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...
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
More information about the Mir-devel