Age | Commit message (Collapse) | Author |
|
|
|
Such visuals are subject to automatic compositing in the X server, so DRI1
can't render to them properly.
|
|
Fixes a bug where psp->WaitX was uninitialized. Reported by Chris Clayton.
|
|
|
|
|
|
|
|
|
|
Why are we reindenting code that's work in progress...
|
|
|
|
|
|
Was only used to get the PUBLIC/USED macros.
Also, replace "GL_FALSE" with "False" in a couple places.
|
|
|
|
|
|
Fixes bug 15477
|
|
caveats:
- does not work with old (i.e. libGLcore) xserver:
- made unbindContext a noop
- extensions:
GLX_SGI_make_current_read
GLX_EXT_texture_from_pixmap
GLX_MESA_copy_sub_buffer
|
|
|
|
compile tested only
|
|
also drop driFilterModes which is unused
in preparation of loading swrast_dri.so
|
|
Since the only valid consumer of the DRI drivers is the X.Org xserver,
this changes the default DRI driver directory to match xorg-server:
${libdir}/dri. The old default of /usr/X11R6/modules/dri was wrong for
nearly all current systems.
|
|
|
|
also clean header inclusion after code movement
|
|
|
|
Thanks to Adam Jackson for pointing it out.
|
|
|
|
Add DRI2 direct rendering support to libGL and add DRI2 client side
protocol code. Extend the GLX 1.3 create drawable functions in
glx_pbuffer.c to call into the DRI driver when possible.
Introduce __DRIconfig, opaque struct that represents a DRI driver
configuration. Get's rid of the open coded __GLcontextModes in the
DRI driver interface and the context modes create and destroy
functions that the loader was requires to provide. glcore.h is no
longer part of the DRI driver interface. The DRI config is GL binding
agnostic, that is, not specific to GLX, EGL or other bindings.
The core API is now also an extension, and the driver exports a list
of extensions as the symbol __driDriverExtensions, which the loader
must dlsym() for. The list of extension will always include the DRI
core extension, which allows creating and manipulating DRI screens,
drawables and contexts. The DRI legacy extension, when available,
provides alternative entry points for creating the DRI objects that
work with the XF86DRI infrastructure.
Change DRI2 client code to not use drm drawables or contexts. We
never used drm_drawable_t's and the only use for drm_context_t was as
a unique identifier when taking the lock. We now just allocate a
unique lock ID out of the DRILock sarea block. Once we get rid of the
lock entirely, we can drop this hack.
Change the interface between dri_util.c and the drivers, so that the
drivers now export the DriverAPI struct as driDriverAPI instead of the
InitScreen entry point. This lets us avoid dlsym()'ing for the DRI2
init screen function to see if DRI2 is supported by the driver.
|
|
|
|
|
|
This will be shared between dri and dri2 code.
|
|
This may not be correct but it should get the build going.
|
|
|
|
After commit 6fd82f6fbd208dc7b1839ea408a5fb28589ee622, we would
overwrite the libPath default value with NULL if libGL was running
non-setuid and none of the env vars were set.
Thanks to Magnus Kessler <Magnus.Kessler@gmx.net> for spotting it.
|
|
|
|
Also drop isDirect flag; if gc->driContext is non-NULL, it's direct.
|
|
|
|
Temporarily rename the __DRIscreen member to __driScreen. Eventually,
we'll move that into __GLXDRIscreen and only access it in dri_glx.c.
|
|
|
|
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.
|
|
|
|
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 .
|
|
|
|
|
|
Fedora bug #229808.
|
|
|
|
|
|
Else we read memory we just released, in for statement.
|
|
|