| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
We avoid leaking the symbols and will be able to replace them with
DRI2 implementation later on.
|
|
|
|
|
|
|
|
| |
This patch moves __DRIdisplayPrivateRec definition into dri_glx.c and
let's dri_glx.c allocate the __DRIdisplay struct pointer to from
__GLXdisplayPrivate.
A small step towards moving more of the dri functionality into dri_glx.c.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
No need to jump through hoops to track __DRIdrivers and avoid dlopening the
same .so more than twice, dlopen() does this internally. Besides, we
were already bypassing this and dlopening drivers for each screen,
whether or not they were already dlopened.
|
|
|
|
| |
Move a lot of code over from glx_ext.c.
|
| |
|
|
|
|
|
| |
Also, use -include to avoid error message when make initially fails to
include the non-existent depend file.
|
|
|
|
|
|
|
|
|
|
|
| |
The DriverAPI is internal to the DRI drivers and GetDrawableMSC
obsoletes GetMSC. Also, since the DRI driver interface has not yet
been released, just drop the getMSC function from the DRI interface
instead using the ABI preserving version mechanism.
Finally, using void pointer privates in the DRI interface is not allowed,
always pass the actual types around (__DRIdrawable in this case) to
enhance type safety and readability of the code.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of generating the glapi sources for the xserver and commiting
them to the xserver tree, we can keep them in the mesa tree and change
the xserver build to use the files from the mesa tree.
This makes the xserver glx build more robust as it reduces the chances
for mismatches of the glX API used in the xserver vs. in mesa.
|
| |
|
| |
|
|
|
|
|
|
| |
This increases the reference count for the driver binary, preventing it from
getting unloaded prematurely in driDestroyDisplay. See
https://bugs.freedesktop.org/show_bug.cgi?id=13541 .
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
The __GLXcontextRec struct is internal to the libGL implementation. No point
in "deprecating", just get rid of it.
|
| |
|
| |
|
|
|
|
| |
Also, handle visual not found error case by throwing X error.
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Thanks to dri2, xf86dri no longer uses __DRI types.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|