XAA PixmapOps: Sync before accessing unwrapped callbacks.
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.
tested by naddy@ and Edd Barrett. ok oga@.
Apparently the server needs the driver to tell it that no, we really don't want
screen sections on our NIC, USB hubs, bridge devices, etc.
Stop whining about PROBE_DETECT in G80 PreInit and just bail out instead.
Bug #18099: Xorg -configure tries to create a screen for every nvidia device.
Problem also reported by form@
(e.g. the graphics aperture on most video cards), don't error if we
failed to set the mtrr but the map succeeded. Instead print a warning (other
osen handle this case similarly).
Libraries shouldn't use fprintf(stderr, ...); but libpciaccess is really
quite poorly designed.
This diff means that mine and drahn's laptops work with xserver 1.5.
ok kettenis@
