but you disable dri on in the driver build and don't have the via_drm.h
it wants in dri mode. Work around this by changing the #define used to
an openchrome only one, instead of overloading the XF86DRI identifier.
Also disable the DRI build unconditionally.
This is needed here since we don't provide the via DRM module, and i'm
moving libdrm over to using the kernel headers (instead of libdrms own
private copy of same... This is why kernel modules should be developed
in kernel). We won't provide a via drm driver until it is re-written,
since it is full of linuxisms (like futex).
ok matthieu@, discussed with a few. tested by grange@ to prove it was a
no-op functionality wise.
shouldn't get that signal), and this causes problems for our children
since they inherit the ignore.
Pointed out by Jacek Masiulani in pr 6010; thanks!
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@
