On Fri, Sep 9, 2016 at 7:59 AM, Kevin DuBois <kevin.dub...@canonical.com> wrote:
> Hmm, let me try to rephrase my point, I've lost track of what is in > disagreement. We have a new thread "Does Mir have to pretend to be > SurfaceFlinger" that we can talk about our relationship to drivers. So for > further discussion, let's just assume we only have the Mesa platform. > > We have a few different technologies that we're supporting, or aim to > support: > EGL, Vulkan, software-rendering, multimedia decoders, multimedia encoders, > nested-passthrough [1] > > The problem that I see with the current WIP header is that we assume for > the user that they want to use EGL. When they get a MirRenderSurface, they > can immediately plug that resource into the EGL driver. We then try to > support the other technologies by transmuting transmute to other > technologies from there. [2] > > If the answer to "What is a MirRenderSurface" is "A MirRenderSurface is > the common interface that all technologies can use to upload pixel content > to the mirserver" (and stop me here if this is not the right answer) > Synced up with Chris on IRC on this topic, and this seems to be the right answer. Internally, a MirRenderSurface is really just a mf::BufferStreamId. By defining a EGL_KHR_platform_mir and adding appropriate hooks on the driver-side for the various platforms, then we can pass the mf::BufferStreamId to the drivers, and they can do what they want from there. The various non-egl technologies (software, encoders/decoders, nested-passthrough) will take their mf::BufferStreamId and use MirPresentationChain semantics on it. > Then I think that we've already built this in MirPresentationChain. > And I'm wrong here because of eglstreams, which can't really use this idea. > > [1] nested-passthrough is really support for building a generic display > server on top of the mirclient api. > [2] We build MirBufferStream from MirRenderSurface here: > http://bazaar.launchpad.net/~cemil-azizoglu/mir/mir-render- > surface-v3/view/head:/src/include/client/mir_toolkit/ > mir_render_surface.h#L60 > and I'm going out on a limb to assume that there's a similar function for > MirPresentationChain in the works. > > On Thu, Sep 8, 2016 at 2:18 PM, Cemil Azizoglu < > cemil.azizo...@canonical.com> wrote: > >> >>> We quite literally cast MirRenderSurface* to EGLNativeWindowSurface in >>> the current WIP: >>> http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render >>> -surface-v3/view/head:/playground/eglflash_render_surface.c#L112 >>> >> >> Perhaps, I should point out that our EGLNativeWindowType is not (and >> cannot be) 'MirRenderSurface'. It's void*. This is because we (have to) >> pretend to be other platforms (Android). That's what the cast is for. So if >> we get technical, our EGLNativeWindowType is 'void*'. We are not painting >> ourselves in a corner with a type that is not universal enough. So if Mir >> appeared in an EGL header, it would have 'void*' not 'MirRenderSurface*' as >> its native window type. >> >> >>> >>> This is why I'd much rather create an EGLNativeWindowType for the user >>> than try to tell all the drivers out there that they have to adopt >>> MirRenderSurface as their windowing type. >>> >> >> I disagree. A platform absolutely has to define its own type, and the >> drivers must adopt it. (Modulo the fact that we don't impose the >> MirRenderSurface type as that because of the need to support Android.) >> >> >>> Its mesa-specific thinking to think that we can define the window >>> interface for every >>> >> >> There is nothing Mesa-specific here. A platform defines the type and the >> driver implementer adds support for it around that type. This is what every >> platform has to do. (Except, for platforms that we pretend to be...like >> Android). >> >> As you see I'm having to add 'except' to the statements above, because >> Android is the exception, not Mesa. >> >> If we want to redefine our mesa interface, that's alright by me, and its >>> even fine to define our mesa interface to /be/ the mir client interface. >>> The problem is that we're trying to define our windowing type for platforms >>> where we cannot define the windowing type. >>> >> >> We absolutely can and should....except again for Android. >> >> >> >>> It *does* have implications for how we implement MirRenderSurface on >>>> Android; specifically, it means that MirRenderSurface needs to be a >>>> SurfaceFlinger window. But even this doesn't tie Mir to EGL here - if >>>> MirRenderSurface can masquerade as a SurfaceFlinger window it should also >>>> work for Android Vulcan, which expects a SurfaceFlinger window, and *does* >>>> also work for the HW video encoding, which expects a SurfaceFlinger window. >>>> >>>> 2) Its not obvious how to use this. The casting to an >>>>> EGLNativeWindowType has to be pointed out in comment-headers, or gleaned >>>>> from reading example code. >>>>> >>>> >> Mir native window type is not in EGL headers yet. This "non-obvious-ness" >> can easily be fixed when we add it in https://www.khronos.org/regist >> ry/egl/api/EGL/eglplatform.h >> as a platform. >> >> >> >>> 3) It puts MirPresentationChain and MirBufferStream as second-class >>>>> citizens. Having to >>>>> >>>> >> Who says that they should be first-class citizens? They are specific >> implementations that are prone to change and deprecation. That said, the >> fact that you can't use a MirRenderSurface without a backing of BS or PC >> would still make them a "first class citizen" anyways. >> >> Regards, >> >> Cemil >> >> >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
