Age | Commit message (Collapse) | Author |
|
Conflicts:
Makefile
src/mesa/main/version.h
Resolved by keeping version strings from master (also in the intel driver).
|
|
Apparently the higher compiler optimization level in non-debug builds was
eliminating the unused functions referencing the unresolved DRI2 symbols...
|
|
|
|
|
|
|
|
|
|
This needs a patch for xserver/glx also. An enviroment variable will be added
at some point, it chould be for swrastg only or all gallium drivers.
|
|
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
|
|
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
|
|
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>
|
|
|
|
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
allocated
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 96ab4d2b84178209ee59017458d9964b32b7e183)
|
|
allocated
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>
|
|
If the server supports the OML related protocol, enable support for the
extension.
|
|
Leftover from earlier commit.
|
|
I wasn't careful enough when removing support for GCC versions earlier
than 3.3.0. I could have sworn that I compile tested before pushing,
but apparently not. FAIL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
See fd.o bug 26832.
|
|
|
|
The array stack space wasn't allocated to the proper size. Fixes out of
bounds memory writes when the client/array stack depth exceeds one.
See fd.o bug 26768.
|
|
Fix glX_proto_recv.py and glX_proto_send.py, and regenerate the sources.
|
|
|
|
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
This may break the SUNOS4 build, but it's no longer relevant.
|
|
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.
|
|
|
|
|
|
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>
|
|
|
|
|
|
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.
|
|
|
|
A long time ago I was a bit over-agressive in refactoring context
creation into a single function. The creation code for
glXImportContextEXT does not belong in CreateContext because it does
not use any GLX protocol. The big if-statement for the import case
routed around almost the entire function anyway.
|
|
Passing the screen parameter to CreateContext will simplify a couple
of changes that are coming.
|
|
Passing the opcode directly instead of having CreateContext infer it
from the value of fbconfig and the use_glx_1_3 flag will simplify some
changes that are coming.
|
|
It appears that, in spite of what the spec says, the interval
parameter to glXSwapIntervalMESA has been an unsigned int since
day-1. This made the 'if (interval < 0)' test useless. The test is
removed and the spec is updated to note that the interval is an
unsigned value.
|
|
|
|
|
|
|
|
The wrapper macro GC_IS_DIRECT is used in CreateContext and a couple
other places to eliminate the need for some of the '#ifdef
GLX_DIRECT_RENDERING' madness. There appear to be a *LOT* of places
in glxcmds.c where '#ifdef GLX_DIRECT_RENDERING' is missing.
|
|
Argh, forgot to commit this fix before pushing.
|
|
|
|
After that commit, some dri2 protocol symbols were being checked from
places that weren't including dri2proto.h, effectively disabling some
valuable SwapBuffers codepaths.
|
|
I'd like to be able to build mesa on current distro releases without
having to upgrade from the standard dri2proto and glproto headers. With
this change I'm able to build on ancient releases such as Ubuntu 9-10...
In general, it would be nice to be able to build-test mesa to check for
unintended breakages without having to follow the external dependencies
of every group working on the codebase.
Seems to introduce no changes to the build of libglapi.a when tested against
new versions of the headers.
|