Does Mir have to pretend to be SurfaceFlinger?

[Christopher James Halse Rogers]

On Fri, Sep 9, 2016 at 9:25 PM, Kevin DuBois 
<kevin.dubois at canonical.com> wrote:
> I'm glad that the topic of EGL platforming was split off, its a 
> different question than the one I was raising in the "What is a 
> MirRenderSurface?"
> 
> So really the question here is "should Mir have its own 
> EGL_KHR_platform_mir". I'm not opposed to this in general.
> 
> This goes back to the charter that we were given at the start of Mir, 
> which is to accept drivers as they come to us, especially if they 
> come to use in binary form with no intention from the driver authors 
> to change anything about their drivers. The notable example of this 
> is the Android platform, but the wider intention is to stay flexible 
> for closed-source binary drivers that have been coming our way.
> 
> So if we re-examine that question and decide that we're our own 
> platform, then we can bolt other technologies on top via the use of 
> shims and such. It is a bit more work for 'non-mir' platforms, 
> especially when we have to deal with hybris and creating shim 
> libraries and such to wrangle things into a mir-platform-interface 
> (which at this point we don't define).

Mir is *already* our own platform. There are Mir things that you pass 
to eglGetDisplay to get an EGLDisplay and Mir things you pass to 
eglCreateWindowSurface to get an EGLSurface. We cannot support EGL and 
*not* be a platform.

The fact that you can sometimes cast the result of 
mir_buffer_stream_get_egl_native_window() to an ANativeWindow* and 
sometimes not doesn't change the fact that the return type of 
mir_buffer_stream_get_egl_native_window() is Mir's EGLNativeWindowType.

2) Android is really, really special. Android drivers are the only 
binary drivers we're *ever* going to be able to use without vendor 
support, and that's only because the Android platform was specifically 
designed to be plugged into without vendor support.

Closed-source binary drivers have to support *some* platform, and the 
set of platforms they can support is {Android, Windows, OS X, X11, 
Wayland}. Of those, there's exactly one we could use - Android.

Not being a platform doesn't make it easier for us to support 
non-Android closed source drivers. It makes it harder for closed-source 
drivers to support *us*.


> I'd rather just continue saying that Mir is a WindowManager that can 
> take plugins to different platforms, as opposed to saying Mir is a 
> WindowManager and NativeWindowType, and non-mir platforms have to be 
> adapted to the mir platform. It also is 'staying the course' as far 
> as the story that we've been promulgating to driver developers.

I don't think it's relevant for driver developers, with, again, the 
exception of Android. It's just not possible for us to take a, say, 
Xorg-targetting binary driver and support it in Mir without 
implementing Xorg; we can't take a Windows-targetting binary driver 
without implementing a bunch of the Windows kernel, and we can't take a 
Wayland-targetting binary driver without implementing a Wayland 
server¹.

Having MirRenderSurface* as our native window type doesn't constrain 
driver developers; their existing EGL was going to take an X11 Window*, 
or a wl_surface, or a HWND, and there's no way they're going to want to 
fake an X11 connection, a Wayland connection, or the Windows kernel 
inside their Mir client platform. They'll use Mir API², because 
there's literally nothing else they could more easily do.

That only works for Android because it's fundamentally designed for it 
- and because Android is fundamentally designed for it, it's no easier 
to do in the client platform than in a libEGL.

> 
> IMHO, The decision to define our own windowing type is something that 
> will affect more than just the mir team (it has to do a bit with 
> strategy), so would be good to get input from a wider audience.
> 
> 
> 
> On Thu, Sep 8, 2016 at 10:26 PM, Christopher James Halse Rogers 
> <chris at cooperteam.net> wrote:
>> Thinking about this further, I think we'll *have* to implement a 
>> shim libEGL in the not-too-distant future. We can't propose or use 
>> EGL_KHR_platform_mir unless we implement it on the Android stack. 
>> (And we want to, because it's useful in certain cases).
>> 
>> So I therefore think we *should*:
>> #define EGLNativeWindowType MirRenderSurface*
>> #define EGLNativeDisplayType MirConnection*
>> 
>> implement our libEGL shim providing the Mir platform on Android, and 
>> deprecate mir_connection_get_egl_native_display() and not implement 
>> mir_render_surface_get_egl_native_surface().

¹: However much of a good or bad idea that might be ☺.
²: It would be nice if we could give them a fully featured extension 
mechanism to use, rather than our current emaciated 
mir_platform_operation pseudo-extension mechanism.