mir on mir questions :)

[Alan Griffiths]

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

On 12/06/13 10:32, Alexandros Frantzis wrote:
> 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
> 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.
>
>> 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
>> 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
> {
>     return the_native_platform();
>     or
>     return the_nested_platform();
> }
>
> Thanks,
> Alexandros
>