On Fri, Sep 9, 2016 at 9:25 PM, Kevin DuBois
<kevin.dub...@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
<ch...@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.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
