I was hitting this with gliv.
The GLX spec explicitly mentions that glXWaitX, glXWaitGL and glXUseXFont calls
are ignored when there's no current context. Not sure what if anything the
GLX_EXT_texture_from_pixmap spec says about this, but I think ignoring the
calls makes more sense than crashing there as well. :)
Code in glx/glxcmds.c which uses the XF86VIDMODE extension is already guarded. Also use
that guard to control inclusion of the xf86vmode.h header, and only enable that guard if the
XF86VIDMODE extension is found by pkgconfig.
This changes the behaviour on platforms which XF86VIDMODE exists, in that XF86VIDMODE used to
be mandatory, but is now optional.
Presumably other build systems are already arranging for -DXF86VIDMODE to be supplied to the
complier when glxcmds.c is compiled, so are not affected by this change
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
This fixes some of the build issues with GLX_INDIRECT_RENDERING but !GLX_DIRECT_RENDERING due to recent changes.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
GLXscreenConfigs is badly named and a dumping ground for a lot of stuff.
This patch creates private screen structs for the dri drivers and moves
some of their fields over there.
And lookup the GLX screen for the context. Otherwise we'll end up
jumping through a NULL-pointer once we try to look up the visual
or config for the shared context.
https://bugs.freedesktop.org/show_bug.cgi?id=14245
When matching attributes using the 'mask' matching criteria, the spec
says that
"Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute)."
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When matching attributes using the 'mask' matching criteria, the spec
says that
"Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute)."
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This change passes a remainder of 1 to the server with the
DRI2SwapBuffers request, causing it to honor the OML semantics for the
swap rather than falling through to glXSwapBuffers behavior. The
remainder actually ends up ignored since the divisor is 0, but we need
to differentiate the OML and standard behavior somehow.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This merges the patches from the series "[PATCH 00/14] More
client-side GLX house cleaning" that were posted to the mesa3d-dev
mailing list. See
http://marc.info/?l=mesa3d-dev&m=126582985214612&w=2
Patches 01 through 04 eliminate a bunch of annoying warnings that I
get when building Mesa.
Patch 05 fixes an inconsistency between the implementation of
glXSwapIntervalMESA and the spec. I chose to favor the code over the
spec in this case. This also eliminated a warning.
Patches 06 through 12 clean up the way that context creation is
performed on the client. When support for GLX_SGIX_fbconfig and the
related GLX 1.3 functions was added, I refactored a bunch
nuts-and-bolts of context creation to CreateContext. The refactor was
a good idea, I just didn't do it right.
Patches 13 and 14 update glxgears_fbconfig to use GLX 1.3 interfaces.
Pass either the fbconfig ID or the visual ID, as appropriate, to
CreateContext. Now CreateContext does not derefernce fbconfig or vis
(which no longer exists as a parameter).
For the direct rendering case, the DRI createContext function wants an
fbconfig. When glXCreateContext is called, we have to convert the
visual to an fbconfig. This work was done in CreateContext, but it
makes more sense for it to be done in glXCreateContext.
