The previous scheme didn't work when the client didn't create the core drawable,
e.g. the root or composite overlay window. Use refcounting via special client
resources to fix that.
This is to avoid issues with redirected windows which are located partly or
fully outside of a screen edge, resulting in unusual cliprects which the 3D
drivers generally can't handle. The symptoms in such cases would be incorrect
rendering or even crashes or hangs.
When available, use the 2D driver texOffsetStart hook and the 3D driver
setTexOffset hook to save the overhead of passing the pixmap data to
glTex(Sub)Image.
The basic idea is to update the driver specific 'offset' for bound pixmaps
before dispatching a GLX render request and to flush immediately afterwards
if there are any pixmaps bound. This should ensure that the 3D driver can
use pixmaps for texturing directly regardless of the X server moving them
around.
Previously, the new mode was added at the head of the list. This caused the
positional correspondence between modes and the XMesaVisuals array to be off
by one. The net result was GLX clients failing when they tried to use the
last GLX mode/visual.
We still have the problem of DRI drivers not being able to use the extra
mode/visual introduced by __glXCreateARGBConfig(). glXCreateContext fails
with BadAlloc if it's attempted. This is also the source of the often-
seen warning "libGL warning: 3D driver claims to not support visual xxx"
Look into fixing that someday...
As the driver EnterVT function generally re-enables the hardware and
prepares it for rendering, it must be called before any gl functions are
called which could touch the hardware.
Use newly added XMesaCopyContext() and drop the GlxSetRenderTables() call
for Xgl, as this is now done inside XMesaForceCurrent(). This leaves xmesaP.h
but only for the declarations of the three XMesa/XFree86 functions. Also,
GlxSetRenderTables() stays but is only used in hw/xgl/glxext/ .
Also drop xf86glxint.h, no longer used.
Depends on mesa commit 7439a36785b6a2783e80a40a96c09db8f56dc2bc of 2007-03-30.
Move the byte-order related wrappers out of the individual source
files into a dedicated header file. Modify the single hand-coded
source file that uses the byte-order wrappers to use the new header
file.
- Use autoconf tests instead of platform-specific #ifdef's to decide
which macros to use.
- Provide fallbacks for platforms like Solaris that don't provide any
of the existing known forms.
defining __GLIBC__, as done already for Linux and Hurd (cf. bug #5613).
Also includes some more __GNU__ checks on top of those made in
commit ade4bf0907.
Thanks Petr Salinger (Debian bug #400869).
The logic for freeing GL contexts introduced by "Fix AIGLX VT switching." is
inverted. As it is now, GL context destruction is deferred for glxDRIEnterVT().
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.
This is just a server-side regeneration from gl_API.xml version 1.68.
GLX protocol isn't supported for GLX_SGI_swap_control or
GLX_SGI_video_sync. Remove them from the list of available extensions
until they are supported.
Re-generate from gl_API.xml 1.65. This provides the missing bits for
GL_EXT_texture_filter_anisotropic and GL_EXT_blend_equation_separate.
Enable those extensions.
Implement glGetProgramStringARB and glGetProgramStringNV. With these
functions implemented, GL_ARB_{vertex,fragment}_program,
GL_NV_{vertex,fragment}_program, and related extensions can be enabled.
Fill in __glXDisp_GetCompressedTexImageARB and
__glXDispSwap_GetCompressedTexImageARB to finish support for
GL_ARB_texture_compression. With this extension (and the related
compression extensions), the server-side GLX supports all of the
protocol for GL 1.4. w00t!
The bad news is that this has received only minimal testing, and Mesa
does not contain any good tests for GL_ARB_texture_compression.
