If the server didn't send a value, assume it's not supported.
A more generic solution might be better for this kind of problem, but an
attempt for this failed (see https://bugs.freedesktop.org/show_bug.cgi?id=9264)
and this allows compiz to work with drivers that support
GL_EXT_framebuffer_object.
Consolidate support for synchronizing to and retrieving vblank counters. Also
fix the core vblank code to return monotonic MSC counters, which are required
by some GLX extensions. Adding support for multiple pipes to a low level
driver is fairly easy, the Intel 965 driver provides simple example code (see
intel_buffers.c:intelWindowMoved()).
The new code bumps the media stream counter extension version to 2 and adds a
new getDrawableMSC callback. This callback takes a drawablePrivate pointer,
which is used to calculate the MSC value seen by clients based on the actual
vblank counter(s) returned from the kernel. The new drawable private fields
are as follows:
- vblSeq - used for tracking vblank counts for buffer swapping
- vblFlags - flags (e.g. current pipe), updated by low level driver
- msc_base - MSC counter from the last time the current pipe changed
- vblank_base - kernel DRM vblank counter from the last time the pipe changed
Using the above variables, the core vblank code (in vblank.c) can calculate a
monotonic MSC value. The low level DRI drivers are responsible for updating
the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags)
along with msc_base and vblank_base whenever the pipe associated with a given
drawable changes (again, see intelWindowMoved for an example of this).
Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to
driDrawableGetMSC32 and add code for pipe switching as outlined above to fully
support the new scheme.
The old version just set GLX_DRAWABLE_TYPE to GLX_WINDOW_BIT for
configs received through glXGetVisualConfigs and to
GLX_WINDOW_BIT | GLX_PIXMAP_BIT for configs received as FBConfigs.
The X server needs to send this info, but keep the workaround for now.
Fixes#12835.
The old implementation fetches fbconfigs or glx visuals once and assumes the list
describes both fbconfigs and glx visuals. This patch splits it up and fetches
visuals and fbconfigs in two steps and keep the two lists separate. A server
could have no glx visuals or no glx fbconfigs and the old code wouldn't know the
difference.
This new API lets the loader examine DRI level extensions provided by the
driver in a forward compatible manner.
Much of the churn in the DRI interface is adding support for new
extensions or removing old, unused extensions. This new extension
mechanism lets the loader query the extensions provided by the driver
and implement the extensions it knows about. Deprecating extensions
is done by not exporting that extension in the list, which doesn't
require keeping old function pointers around to preserve ABI.
The entrypoints take a mix of __DRIscreen * and void * (screen private)
arguments (similarly for contexts and drawables). This patch does away
with passing the private void pointer and always only passes the fully
typed __DRIscreen pointer and always as the first argument.
This makes the interface more consistent and increases type safety, and
catches a bug where we would pass a screen private to DRIdrawable::getSBC.
The screenConfigs field of __DRIscreen points back to the containing
__GLXscreenConfigs struct. This is a serious abstraction violation; it
assumes that the loader is libGL and that there *is* a __GLXscreenConfigs
type in the loader.
Using the containerOf macro, we can get from the __DRIscreen pointer to
the containing __GLXscreenConfigs struct, at a place in the stack
where the above is a valid assumption. Besides, the __DRI* structs shouldn't
hold state other than the private pointer.
__glXinitialize() can't be called with the GLX lock held. Just
pass in the __GLXscreenConfigs pointer so we don't have to look it
up in __GLXdisplayPrivate.
As for createDrawable and destroyDrawable, these functions immediately
upon entry to driCreateNewContext and immediately before exit from
driDestroyContext. Instead of passing function pointers back and forth
just obtain the drm_context_t prior to calling DRIscreen::createNewContext
and pass it as a parameter.
This change also lets us keep the DRI context XID in the libGL loader only.
All the DRI driver did was call the createDrawable callback immediately
upon entry to DRIscreen::createNewDrawable to get the drm_drawable_t.
We can just call that before calling into the DRI driver and pass the
returned drm_drawable_t as an argument to the DRI entry point.
Likewise for destroyDrawable.
Also, DRIdrawablePrivate::draw isn't used anywhere, and since the
driver no longer needs the XID of the drawable we can now drop that.
Many DRI entry points took a __DRInativeDisplay pointer and a screen
index as arguments. The only use for the native display pointer was to
pass it back to the loader when looking up the __DRIscreen for the given
screen index.
Instead, let's just pass in the __DRIscreen pointer directly, which
let's drop the __DRInativeDisplay type and the getScreen function.
The assumption is now that the loader will be able to retrieve context
from the __DRIscreen pointer when necessary.
