| Age | Commit message (Collapse) | Author |
|---|
|
Follow on to cherry-pick from master
|
|
Don't define ASM_SOURCES variable globally -- reserve that variable to be defined
locally by makefiles, together with C_SOURCES and CPP_SOURCES.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes miniglx take not of the x and y from XCreateWindow
|
|
|
|
|
|
|
|
Fedora bug #229808.
|
|
|
|
|
|
|
|
move memory macros to separate block and unwrap malloc/free for miniglx towards
cleaning Mesa core glitches in glx...
|
|
It is no longer linked with DRI drivers, libGL passes function pointers through
the DRI interface.
|
|
|
|
|
|
Else we read memory we just released, in for statement.
|
|
|
|
|
|
|
|
This fixes a regression from commit f81b1dbe374fe446f6ef676e70a72952ffb47d4e:
Since then, driDestroyDisplay gets called from __glXFreeDisplayPrivate. It
dlcloses the handles associated with the display but fails to remove their
references from the Drivers list, so subsequent calls to OpenDriver return a
stale handle and an invalid createNewScreenFunc pointer. The attempt to call
the latter results in a segfault when running amoeba, e.g.
|
|
|
|
|
|
|
|
With this, tools like ximagesrc in gstreamer correctly see updates from GL
rendering. Support requires that the Xdamage library be current (but will be
disabled if not present) plus a new X Server with support for the new
XDamagePost request. libGL now has a new interface version, and also links
against libXdamage and libXfixes to support it, but backwards compatibility
is retained.
Currently, all drivers report damage at SwapBuffers time through common code --
front buffer rendering doesn't result in damage being reported. Also, the
damage is against the root window, as our drivers don't yet render to backing
store when they should (composited environments).
|
|
|
|
|
|
requires hacks to DRM to remove MASTER from UPDATE_DRAW and ADD_DRAW
|
|
|
|
|
|
|
|
|
|
|
|
Fixes a GLX protocol problem when binding an indirect rendering context
after a direct rendering context. In this case, the oldContetTag sent to
the server should be None, but the currectContextTag stored in the direct
rendering context (i.e., -1) was sent instead.
|
|
I always build with -DGLX_USE_TLS, so I never hit these paths. glapi.h is
required in some places because _glapi_Dispatch is declared there, but
_glapi_tls_Dispatch is declared in glthread.h.
|
|
|
|
glDeleteTextures and glDeleteTexturesEXT were erroneously listed as
aliases of each other. For anything /except/ GLX protocol they are
aliases. This set of changes allows functions that are functionally
identical but have different GLX protocol to be listed as aliases.
When building with GLX_INDIRECT_RENDERING set, different static
functions are used. These functions determine whether the current
context is direct rendering or not. If the context is direct
rendering, the aliased function (e.g., glDeleteTextures in the case of
glDeleteTexturesEXT) is called. If the context is not direct
rendering, the correct GLX protocol is sent.
For a deeper explanation of what is changed, please see:
http://dri.freedesktop.org/wiki/PartiallyAliasedFunctions
|
|
|
|
|
|
Rearrange most of the internals of MakeContextCurrent. Put all of the code to
bind the new context up front. If that is successful, unbind the old context.
This saves a lot of code and removes some locking crazyiness.
This patch has been tested for indirect rendering with glxinfo, glxgears,
manywin, and wincopy.
|
|
|
|
bug 8443
|
|
|
|
There were two sets of bugs in the vertex program (ARB and NV)
protocol. First, several of the ARB functions were missing the
'doubles_in_order="true"' annotation. Second, after the ARB decided
that glVertexAttrib*ARB functions must not alias fixed-function state
for GLSL, Nvidia re-assigned GLX protocol opcodes for
glVertexAttrib*NV (circa Septeber 2004). For some reason gl_API.xml
was never updated to reflect this, and the updated version of the
GL_NV_vertex_program spec never made into the registry.
|
|
correctly generated.
|
|
Nvidia no longer supports this extension, and they no longer export its
entry points from their libGL. There's no reason for us to keep dragging it
around either.
|
