<div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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).:</div><div><br></div><div>By adding a small variant in creating the display (nicked from the above mentioned example):<br></div><div><br></div><div>gst-libs/gst/gl/egl/gstgldisplay_egl.c</div><div><br></div><div>-  _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)<br>+  if (!_gst_eglGetPlatformDisplay)<br>+    _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)<br>+        eglGetProcAddress ("eglGetPlatformDisplayEXT");<br>+  if (!_gst_eglGetPlatformDisplay)<br>+    _gst_eglGetPlatformDisplay = (_gst_eglGetPlatformDisplay_type)</div><div><br></div><div>And starting <br></div><div><br></div><div> 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</div><div><br></div><div>everything seems to hook up and the pipeline goes to playing.</div><div><br></div><div>However, nothing is displayed. probably related to this.<br></div><div><br></div><div><br></div><div>0:00:00.124841759 19331 0x563eaca48c00 DEBUG            glimagesink gstglimagesink.c:1357:configure_display_from_info: keeping video height<br>0:00:00.124859669 19331 0x563eaca48c00 DEBUG            glimagesink gstglimagesink.c:1375:configure_display_from_info: scaling to 320x240<br>New clock: GstSystemClock<br>0:00:00.124935373 19331 0x563eac9ae230 DEBUG            glimagesink gstglimagesink.c:2124:gst_glimage_sink_on_resize:<sink> GL Window resized to 0x0<br>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<br>0:00:00.124958842 19331 0x563eac9ae230 DEBUG            glimagesink gstglimagesink.c:2189:gst_glimage_sink_on_resize:<sink> GL output area now 0,0 1x0<br>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<br>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.<br>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.<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 14 Jun 2019 at 14:53, Marc Leeman <<a href="mailto:marc.leeman@gmail.com" target="_blank">marc.leeman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Some bit if success,</div><div><br></div><div>after backporting mesa 19.1.0 to debian 10 and using the nouveau drivers, mutter starts again</div><div><br></div><div>My patched GStreamer (ugly as hell) is able to start <br></div><div><br></div><div>videotestsrc ! glimagesink</div><div><br></div><div>the plugins-base master fails, if I were to guess, it has to do with the new colour spaces that are exposed:</div><div><br></div><div>eglChooseConfig returns [R, G, B, A] [10, 10, 10, 0].</div><div><br></div><div>I'll weed out the relevant parts.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 13 Jun 2019 at 15:35, Marc Leeman <<a href="mailto:marc.leeman@gmail.com" target="_blank">marc.leeman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Be aware that on Intel/Mutter, it works for me, I don't have an NVidia<br>
setup. Did you try with NVidia/Nouveau first ? I suspect it has to do<br>
with EGLStream, as with NVidia blob, Wayland/GL is different.</blockquote></div><div></div><div><br></div><div>mesa does not even support that chipset (Quadro M4000) properly it seems; when  mutter probes the display, it gets an EGL_NO_DISPLAY.</div><div><br></div><div>I'll have a look if I can bump mesa to a more recent version, but that one depends on clang-8 :-/</div><div><br></div><div>Welcome to dependency hell.</div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_7138811711264839632gmail-m_-6683886607403075669gmail_signature">g. Marc</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_7138811711264839632gmail_signature">g. Marc</div>