When using any XAAPixmapOps, we call into unknown but freshly
unwrapped callbacks (like fb ones). Unlike the XAA*Fallback calls,
we did so without syncing first, exposing us to all kinds of
synchronisation issues.
I believe that the rendering errors appeared now because *PaintWindow
vanished (e4d11e58), and we just use miPaintWindow instead. This
takes a less direct route to the hw and ends up at
PolyFillRectPixmap, which very often left drawing artifacts.
We now sync accordingly, and no longer get the rendering artifacts i
was methodically reproducing on radeonhd, radeon, unichrome...
Also, in order to allow driver authors to remove extensive syncing
or flushing to hide this issue, create XAA_VERSION_ defines, put
them in xaa.h and bump the patchlevel.
(novell bug #435791)
(cherry picked from commit 59f9fb4b8c)
When setting the depth to 24, leave bpp unset so the logic to pick
a supported value is used instead of ignoring the driver's preference
and forcing 32 bpp.
(cherry picked from commit 991c88b754)
The swrast DRI provider gets pushed on the glx provider stack at every
server generation, so the stack turns into a circular list on regen.
X.Org bug#18388 <https://bugs.freedesktop.org/show_bug.cgi?id=18388>
(cherry picked from commit d3d6be4948)
When the linux kernel sets the NX bit vm86 segfaults when it tries to execute
code in memory that is not marked EXEC. Such code gets called whenever
we return from a VBIOS call to signal the calling program that the call
is actually finished and that we are not trapping for other reasons (like
IO accesses).
Use mprotect(2) to set these memory ranges PROT_EXEC.
(cherry picked from commit a9e20306fb)
Add various GLX extensions to the list of supported extensions.
Reformat the oddly formatted code in some areas.
Use xalloc and xfree instead of malloc and free.
Add some commentary about future directions needed for the GLX drawable
creation and destruction code.
Match xalloc with xfree.
I made some minor formatting improvements.
In attach() check for pDraw being NULL, and also print an ErrorF message,
because we eventually want to track down why this is occuring.
It's unclear how this occurs, but as I noted in the 1.4 branch, I believe that
the DrawablePtr/struct _Drawable -> id is the member being accessed that causes
KERN_PROTECTION_FAILURE at 0x0000000000000004
This passes my tests using: env LIBGL_ALWAYS_INDIRECT=1 ./sometest.
I fixed a warning: caused by initializing the screen->base.visuals with the
configs. It is a ** not a *. It seems that some other part of GLX will
initialize this for us.
It looks much better with the new GLX/libGL, perhaps because of the old libGL
not understanding all of the tags written. At least glxgears works with both.
glxgears is not a test for all OpenGL features, so most likely some things
are broken still. Direct rendering is known to not work, or at least being
reported as not working.
Fix some obvious errors with uninitialized new members of GLX structs.
Add a type argument for the screen's drawable creation function, and pass the type to
__glXDrawableInit().
GLX still doesn't work. There is more work needed to get it working again. This gets
it building at least, although there are some warnings in the dispatch table setup,
that seem to be caused by const differences.
I also #if 0ed a bunch of function bodies that will need to be revisited soon.
