There were several bugs in the infrastructure for these two routines.
1. GLX_ALIAS was incorrectly used. The function and its alias must be
identical! glXMakeContextCurrent / glXMakeCurrentReadSGI and
MakeContextCurrent had different parameters. This caused the last
parameter of MakeContextCurrent to get random values.
2. We based the implementation of glXMakeContextCurrent on the manual
page instead of the GLX spec. The GLX spec says that
glXMakeContextCurrent can be passed a Window as a drawable. When this
happens, it will behave just like glXMakeCurrentReadSGI or
glXMakeCurrent.
3. If there was a problem finding or creating the DRI drawable,
MakeContextCurrent would crash instead of returning an error.
This commit fixes all three issues, and fixes bug #18367 and bug #19625.
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
This utility is useful for hardware that doesn't support HW index buffers.
It's a bit inefficient but appears to give a substantial performance gain,
as we can emit tri strips that would otherwise be split into triangles.
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
Since we use an inverted viewport transformation for render to texture, that
inverts front/back polygon orientation.
Now glCullFace(GL_FRONT / GL_BACK) works correctly.
OpenGL allows mixing and matching depth and stencil renderbuffers in
framebuffer objects while the hardware really only supports interleaved
depth/stencil buffers. This makes for some tricky buffer management.
An extra wrinkle is the situation where the user allocates a 16bpp depth
texture or renderbuffer then tries to render to it along with a stencil
buffer. We'd have to promote the 16bpp Z values to 24-bit Z values and
mix in the stencil values to setup the depth/stencil renderbuffer.
There's no support for that now, so always allocate 32bpp depth textures/
renderbuffers for now.
Brian Paul