Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Using XCB event processing is incompatible with GLX on DRI2 #47
GPU, drivers, and screen setup
Intel graphics (Skylake), modesetting driver, mesa 18.2.4
name of display: :0.0
OpenGL version string: 3.0 Mesa 18.2.4
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.4
Steps of reproduction
Screen does not flicker horribly
Screen flickers horribly
Note: skipped commit 43f3744 because it fails to build:
Here is a video in case it's not obvious what horrible flickering looks like:
This part is interesting, it's exactly the same as what I see:
@yshui I investigated this a bit more this morning and it seems to be specific to DRI2. With DRI3 or software rendering (LIBGL_ALWAYS_SOFTWARE=1), the flickering goes away.
Looking at mesa source (dri2.c), one can see that it is in fact incompatible with xcb event processing due to usage of XESetWireToEvent()/XESetEventToWire(), which hook into the traditional Xlib event processing. Without Xlib in the loop, DRI2 misses its Invalidate events and the result is that glXSwapBuffers() doesn't work as expected. (Take a look at dri2_glx.c - dri2XcbSwapBuffers() contains an explicit XSync() call to wait for Invalidate events, which it never gets.)
So it seems that by switching to xcb event processing, you have in effect made compton no longer work on DRI2 setups. I guess it's up to you whether you care about this or not. Personally, I will give DRI3 a try again and see if it is more stable than the last time I experimented with it. If not, I guess I can continue using an older version of compton.
Yes, That is consistent with #34
I guess one have to use the Xlib event processing to use GLX then... This is quite annoying.
Of course, I wish to make compton compatible with as many setups as reasonably possible. We switched from Xlib event processing to xcb because there is a bug in Xlib that caused screen freeze in compton. And I don't have enough faith in Xlib to believe this kind of problem won't happen again.
But then this bug happened. Now I'm not sure what is the best thing to do here.
I was about to say that requiring DRI3 might be a reasonable option -- but if nouveau is still on DRI2 by default, that's less than ideal.
I am not sure what to suggest here either. Maybe it would be good to start by at least filing a bug/feature request against Mesa (to update DRI2 to work properly with xcb), and see what the response is.
Edit: I added a comment to your nouveau bug with some of my analysis, hopefully that helps:
@jlindgren90 Found a workaround in mesa bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35945#c4
Will try implementing it later today.
Ugh, it gets worse than that. Here is the full workaround in Qt:
It would be much better for this to be fixed on the mesa side.
referenced this issue
Nov 10, 2018
@jlindgren90 This has been known for at least 6 years, and isn't fixed yet...
Fix this in Mesa might require some coordinated effort from both libxcb and Mesa, I don't know how hard it is.
BTW, we don't need most of the Qt workaround code, since they are just dealing with Qt internal event handling.