We only need this when the server may have swapped the buffers or
when we receive an invalidate event from the server. The default
behaviour is still that the DRI driver will invalidate its own buffers
when glViewport is called.
https://bugs.freedesktop.org/show_bug.cgi?id=27277
In the direct rendered case, we need to tell the server our initial swap
interval. If we don't, the local and server values will be out of sync,
since the server and client defaults may be different (as they were
before this patch).
The IDs will be the same in the case where an X window is used directly
as a GLX drawable, but will fail if a new GLX drawable is created
explicitly, as with glxgears_fbconfig.
Fixes fdo bug #27190.
Move the initialization of ext_list_first_time from all of the DRI loader's
CreateScreen routines, to where the storage for the screen config is
allocated.
It needs to get set in the screen-config even if DRI is forced off
using LIBGL_ALWAYS_INDIRECT, so that psc->direct_support is initialized
correctly, otherwise __glXExtensionBitIsEnabled() always returns FALSE
Specifically, this causes a problem with an X server which advertises
GLX<=1.2, and the GLX_SGIX_fbconfig extension.
glXGetFBConfigFromVisualSGIX() uses __glXExtensionBitIsEnabled() to
check if the GLX_SGIX_fbconfig extension is available, but that function
won't return correct information because that data has never been
initialized, because ext_list_first_time was never set...
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 96ab4d2b84)
When a buffer invalidation event is received from the X server, the
"invalidate" hook of the DRI2 flush extension is executed: A generic
implementation (dri2InvalidateDrawable) is provided that just bumps
the "pStamp" sequence number in __DRIdrawableRec.
For old servers not supporting buffer invalidation events, the
invalidate hook will be called before flushing the fake front/back
buffer (that's typically once per frame -- not a lot worse than the
situation we were in before).
No effort has been made on preserving backwards compatibility with
version 2 of the flush extension, but I think it's acceptable because
AFAIK no released stack is making use of it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
