gstlglimagesink EGL_BAD_DISPLAY

[Marc Leeman]

After getting stuck in meetings for days and a small side-step to nouveau
(which works), I re-configured my system back to NVidia proprietary.

Comparing a bit with the weston-simple-egl example, I got a little bit
further (I have far too litlle knowledge an EGL, so I'm cross referencing
here).:

By adding a small variant in creating the display (nicked from the above
mentioned example):

gst-libs/gst/gl/egl/gstgldisplay_egl.c

-  _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)
+  if (!_gst_eglGetPlatformDisplay)
+    _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)
+        eglGetProcAddress ("eglGetPlatformDisplayEXT");
+  if (!_gst_eglGetPlatformDisplay)
+    _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)

And starting

 ninja -C build; GST_GL_WINDOW="egl" GST_GL_PLATFORM="egl" WAYLAND_DEBUG=1
GST_DEBUG=*gl*:5 gst-launch-1.0 videotestsrc num-buffers=10 ! queue !
glimagesink

everything seems to hook up and the pipeline goes to playing.

However, nothing is displayed. probably related to this.


0:00:00.124841759 19331 0x563eaca48c00 DEBUG            glimagesink
gstglimagesink.c:1357:configure_display_from_info: keeping video height
0:00:00.124859669 19331 0x563eaca48c00 DEBUG            glimagesink
gstglimagesink.c:1375:configure_display_from_info: scaling to 320x240
New clock: GstSystemClock
0:00:00.124935373 19331 0x563eac9ae230 DEBUG            glimagesink
gstglimagesink.c:2124:gst_glimage_sink_on_resize:<sink> GL Window resized
to 0x0
0:00:00.124951330 19331 0x563eac9ae230 DEBUG                gldebug
gstgldebug.c:320:_gst_gl_debug_callback:<glcontextegl0> low: GL debug
marker from third party id:0, sink window resize to 1x1
0:00:00.124958842 19331 0x563eac9ae230 DEBUG            glimagesink
gstglimagesink.c:2189:gst_glimage_sink_on_resize:<sink> GL output area now
0,0 1x0
0:00:00.124968204 19331 0x563eac9ae230 DEBUG                gldebug
gstgldebug.c:320:_gst_gl_debug_callback:<glcontextegl0> low: GL debug
marker from third party id:0, sink element drawing texture 1
0:00:00.125011697 19331 0x563eac9ae230 ERROR                gldebug
gstgldebug.c:307:_gst_gl_debug_callback:<glcontextegl0> high: GL error from
API id:1286, GL_INVALID_FRAMEBUFFER_OPERATION error generated. Operation is
not valid because a bound framebuffer is not framebuffer complete.
0:00:00.125052271 19331 0x563eac9ae230 DEBUG                gldebug
gstgldebug.c:320:_gst_gl_debug_callback:<glcontextegl0> notification: GL
other from API id:131185, Buffer detailed info: Buffer object 4 (bound to
GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0),
GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), and GL_ARRAY_BUFFER_ARB,
usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for
buffer object operations.





On Fri, 14 Jun 2019 at 14:53, Marc Leeman <marc.leeman at gmail.com> wrote:

>
> Some bit if success,
>
> after backporting mesa 19.1.0 to debian 10 and using the nouveau drivers,
> mutter starts again
>
> My patched GStreamer (ugly as hell) is able to start
>
> videotestsrc ! glimagesink
>
> the plugins-base master fails, if I were to guess, it has to do with the
> new colour spaces that are exposed:
>
> eglChooseConfig returns [R, G, B, A] [10, 10, 10, 0].
>
> I'll weed out the relevant parts.
>
>
> On Thu, 13 Jun 2019 at 15:35, Marc Leeman <marc.leeman at gmail.com> wrote:
>
>>
>> Be aware that on Intel/Mutter, it works for me, I don't have an NVidia
>>> setup. Did you try with NVidia/Nouveau first ? I suspect it has to do
>>> with EGLStream, as with NVidia blob, Wayland/GL is different.
>>
>>
>> mesa does not even support that chipset (Quadro M4000) properly it seems;
>> when  mutter probes the display, it gets an EGL_NO_DISPLAY.
>>
>> I'll have a look if I can bump mesa to a more recent version, but that
>> one depends on clang-8 :-/
>>
>> Welcome to dependency hell.
>>
>>
>>
>>
>
> --
> g. Marc
>


-- 
g. Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190621/48b78242/attachment-0001.html>