After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774809 - glimagesink regression: does not render video since using libxcb
glimagesink regression: does not render video since using libxcb
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-21 19:17 UTC by Mark Nauwelaerts
Modified: 2018-11-03 11:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gl: x11 display glx workaround (942 bytes, patch)
2016-11-21 19:17 UTC, Mark Nauwelaerts
none Details | Review
debug logs (59.36 KB, application/x-compressed)
2016-11-21 19:22 UTC, Mark Nauwelaerts
  Details

Description Mark Nauwelaerts 2016-11-21 19:17:11 UTC
Created attachment 340468 [details] [review]
gl: x11 display glx workaround

More precisely, when running (gst-launch-1.0) the example pipeline videotestsrc ! glimagesink, then a window is created and shown, but it remains as an outline and no content is ever filled (so whatever is behind the window remains visible).

This happens as of commit 4f6c226bd24ae3ef66bd8f4c17b001444c9b0bf1 (using libxcb in gl/x11), it rendered ok before that.  Some additional observations; forcing GST_GL_PLATFORM=egl renders video fine (problem occurs with GST_GL_PLATFORM=glx).  Also, upon applying the attached patch, the video also renders fine with GST_GL_PLATFORM=glx.  It is not really a fix though, as it knocks out the event handling.

All that is rather puzzling, possibly somehow system-specific and might be dismissed as "lower level problems", but still if someone has additional insight (and solution?) ...
Comment 1 Mark Nauwelaerts 2016-11-21 19:22:01 UTC
Created attachment 340469 [details]
debug logs

Debug logs ob *gl* categories for the (failing) glx and (working) egl platform case (additional logs are also easily provided).
Comment 2 Scott D Phillips 2016-11-21 21:22:55 UTC
I also ran into this problem. I think it might be a mesa bug in the dri2 glx glXSwapBuffers code's xcb case. The DRI2_InvalidateBuffers event never gets into mesa so mesa never calls dri2InvalidateBuffers. Everything is OK for me if I'm using dri3.
Comment 3 Julien Isorce 2016-11-21 23:49:24 UTC
Same here and with latest mesa.

The following hack/workaround also fixes the problem:

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index d6eb281..28b8de4 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -853,7 +853,7 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
     }
 
     /* Old servers don't send invalidate events */
-    if (!pdp->invalidateAvailable)
+    if (1 || !pdp->invalidateAvailable)
        dri2InvalidateBuffers(dpyPriv->dpy, pdraw->xDrawable);
 
     return ret;


But looking at the reason why it is working in the egl case, I found this commit:

commit eed0a80137dfac641adfd39ce316938dbcf2be10
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Jun 21 15:34:52 2013 -0700

    egl: Restore "bogus" DRI2 invalidate event code.
    
So I guess one could do something similar than egl, i.e. for glx, having "pdp->invalidateAvailable" equals to false in more cases.
Comment 4 Tim-Philipp Müller 2018-02-08 16:39:24 UTC
Any update on this Julien / Scott ?
Comment 5 Scott D Phillips 2018-02-09 02:22:52 UTC
(In reply to Tim-Philipp Müller from comment #4)
> Any update on this Julien / Scott ?

I'm *far* from an xlib or dri2 expert, so take this with a grain of salt. From some cursory poking around, it looks like the Xext mechanism that Mesa's dri2 code uses for the dri2 extension is just not plumbed through to work with xcb. It seems like the dri2 code would need to be redone with libxcb-dri2 to be compatible. :-(
Comment 6 Julien Isorce 2018-02-16 16:53:35 UTC
I can still reproduce it so I have open a mesa bug https://bugs.freedesktop.org/show_bug.cgi?id=105132
Comment 7 GStreamer system administrator 2018-11-03 11:51:36 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/308.