Initially looking at the gstreamer bug https://bugzilla.gnome.org/show_bug.cgi?id=774809 it seems it could be a pb in mesa:
In src/glx/dri2_glx.c::dri2SwapBuffers psc->f->invalidate is not called when using dri2 on an up to date Ubuntu 16.04. Because the call to dri2InvalidateBuffers is guarded by "if (!pdp->invalidateAvailable)"
But with dri2 and egl the '->invalidate' is always called, see dri3_swap_buffers/loader_dri3_swap_buffers_msc and egl/dri2_x11_swap_buffers_msc
X server is version 1.18.4 and xorg-video-intel is 2:2.99.917
So it looks like xserver/hw/xfree86/dri2/dri2ext.c::DRI2InvalidateBuffersEvent is not called and the comment "/* Old servers don't send invalidate events */" src/glx/dri2_glx.c make sense.
1: Why this difference between dri2 and dri3/egl ? I would have expect the otherway, always called on dri2 and not on dri3.
2: Is "pdp->invalidateAvailable = (pdp->driMinor >= 3);" not accurate ? Should it check for the exact xserver version which contains the fix ?
Thx in advance for any feedback.
It looks like the Xext hooks used by the dri2 code never get called by Xlib when xcb owns the event queue. I think we can either disable invalidateAvailable if xcb owns the event queue (I don't see how to query that), or maybe change the dri2 code to use xcb-dri2.
Could swear I pushed something on the topic - commit c9d449de640f62d83149e64015029b466c44b12c. Which seems to be EGL/x11 :-(
invalidateAvailable is available only for DRI2 1.3+
Having a look at the server side
DRI2Version seems off - it always advertises DRI2 1.2
minor is set based on the driver DRI2InfoRec::version v4, relates to DRI2 1.3
Skimming through a local xorg-video-intel checkout, the only way it advertises v3 or less, is when built against ancient xserver.
So if built correctly, the issue "should not happen" (tm)
Grr scratch that - I missed the negation in from of invalidateAvailable :-\
Created attachment 137438 [details] [review]
wip-not-working: poll special dri2 events
As Scott also mentioned, mesa/src/glx/dri2.c::DRI2WireToEvent is never called when xcb owns the Xlib event queue or as soon as xcb_poll_for_event is called from the app client.
I was curious of what is done for present extension in src/loader/loader_dri3_helper.c, so I mimic that solution, i.e. poll special events by calling "xcb_register_for_special_xge(xcb_dri2_id)" and "xcb_poll_for_special_event".
The attached experimental patch builds and runs but "xcb_poll_for_special_event" does not return any event but it was worth a try. (I am not sending it to mesa-dev as it is an experimentation)
(In reply to Julien Isorce from comment #4)
> The attached experimental patch builds and runs but
> "xcb_poll_for_special_event" does not return any event [...]
That's not surprising, since there are no DRI2 special events. :)
(In reply to Scott D Phillips from comment #1)
> maybe change the dri2 code to use xcb-dri2.
Hi Scott, were you thinking to make https://cgit.freedesktop.org/mesa/mesa/tree/src/glx/dri2_glx.c use more xcb_dri2_* calls ?
Currently it uses a mix, for example it calls "DRI2Connect" but also calls "xcb_dri2_swap_buffers"
The remaining DRI2 calls are:
Looks like https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_x11.c#n612 is a good example for this conversion. Also some refactoring can be done to share the code between mesa/src/glx/dri2_glx.c and mesa/src/egl/drivers/dri2/platform_x11.c
But why it will solve the fact that currently mesa/src/glx/dri2.c::DRI2WireToEvent::dri2InvalidateBuffers is not called when the app owns the event queue ?
(In reply to Michel Dänzer from comment #5)
> (In reply to Julien Isorce from comment #4)
> > The attached experimental patch builds and runs but
> > "xcb_poll_for_special_event" does not return any event [...]
> That's not surprising, since there are no DRI2 special events. :)
Maybe it would have worked if the DRI2 events were generic event: XGenericEvent
which is the case for Xpresent:
Not for dri2: https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/dri2/dri2ext.c#n376
(I believe the "xge" in "xcb_register_for_special_xge" stands for X generic events but I do not know if all generic events are "special")
-- 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/mesa/mesa/issues/110.