[Qemu-devel] [PATCH] egl-headless: add egl_create_context

[Qemu-devel] [PATCH] egl-headless: add egl_create_context

[Gerd Hoffmann]

We must set the correct context (via eglMakeCurrent) before
calling qemu_egl_create_context, so we need a thin wrapper and can't
hook qemu_egl_create_context directly as ->dpy_gl_ctx_create callback.

Reported-by: Frederik Carlier <frederik.carlier@quamotion.mobi>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 ui/egl-headless.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/ui/egl-headless.c b/ui/egl-headless.c
index 4cf3bbc0e4..519e7bad32 100644
--- a/ui/egl-headless.c
+++ b/ui/egl-headless.c
@@ -38,6 +38,14 @@ static void egl_gfx_switch(DisplayChangeListener *dcl,
     edpy->ds = new_surface;
 }
 
+static QEMUGLContext egl_create_context(DisplayChangeListener *dcl,
+                                        QEMUGLParams *params)
+{
+    eglMakeCurrent(qemu_egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE,
+                   qemu_egl_rn_ctx);
+    return qemu_egl_create_context(dcl, params);
+}
+
 static void egl_scanout_disable(DisplayChangeListener *dcl)
 {
     egl_dpy *edpy = container_of(dcl, egl_dpy, dcl);
@@ -150,7 +158,7 @@ static const DisplayChangeListenerOps egl_ops = {
     .dpy_gfx_update          = egl_gfx_update,
     .dpy_gfx_switch          = egl_gfx_switch,
 
-    .dpy_gl_ctx_create       = qemu_egl_create_context,
+    .dpy_gl_ctx_create       = egl_create_context,
     .dpy_gl_ctx_destroy      = qemu_egl_destroy_context,
     .dpy_gl_ctx_make_current = qemu_egl_make_context_current,
     .dpy_gl_ctx_get_current  = qemu_egl_get_current_context,
-- 
2.9.3

Re: [Qemu-devel] [Qemu-devel for-3.1?] [PATCH] egl-headless: add egl_create_context

[Eric Blake]

On 11/29/18 6:35 AM, Gerd Hoffmann wrote:
> We must set the correct context (via eglMakeCurrent) before
> calling qemu_egl_create_context, so we need a thin wrapper and can't
> hook qemu_egl_create_context directly as ->dpy_gl_ctx_create callback.
> 
> Reported-by: Frederik Carlier <frederik.carlier@quamotion.mobi>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>   ui/egl-headless.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)

How severe is this? Is it something that would warrant 3.1-rc4, or are 
we safe deferring it to 4.0?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [Qemu-devel for-3.1?] [PATCH] egl-headless: add egl_create_context

[Gerd Hoffmann]

On Thu, Nov 29, 2018 at 08:09:56AM -0600, Eric Blake wrote:
> On 11/29/18 6:35 AM, Gerd Hoffmann wrote:
> > We must set the correct context (via eglMakeCurrent) before
> > calling qemu_egl_create_context, so we need a thin wrapper and can't
> > hook qemu_egl_create_context directly as ->dpy_gl_ctx_create callback.
> > 
> > Reported-by: Frederik Carlier <frederik.carlier@quamotion.mobi>
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> >   ui/egl-headless.c | 10 +++++++++-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> How severe is this? Is it something that would warrant 3.1-rc4, or are we
> safe deferring it to 4.0?

Fixes segfaults (should probably update the commit message to say so),
therefore 3.1 material IMHO.

cheers,
  Gerd

Re: [Qemu-devel] [Qemu-devel for-3.1?] [PATCH] egl-headless: add egl_create_context

[Peter Maydell]

On Fri, 30 Nov 2018 at 11:29, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Thu, Nov 29, 2018 at 08:09:56AM -0600, Eric Blake wrote:
> > On 11/29/18 6:35 AM, Gerd Hoffmann wrote:
> > > We must set the correct context (via eglMakeCurrent) before
> > > calling qemu_egl_create_context, so we need a thin wrapper and can't
> > > hook qemu_egl_create_context directly as ->dpy_gl_ctx_create callback.
> > >
> > > Reported-by: Frederik Carlier <frederik.carlier@quamotion.mobi>
> > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > > ---
> > >   ui/egl-headless.c | 10 +++++++++-
> > >   1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > How severe is this? Is it something that would warrant 3.1-rc4, or are we
> > safe deferring it to 4.0?
>
> Fixes segfaults (should probably update the commit message to say so),
> therefore 3.1 material IMHO.

Original reporter seems to be saying in the bug report that this
doesn't actually fix his bug ?

Is this a regression from 3.0? It doesn't look like it from a
quick look at the git history, so given that plus the uncertainty
about whether it's actually fixing the bug I'm inclined to defer
this to 4.0.

thanks
-- PMM