it, and we're about to switch to using kernel headers instead of the
ones packaged with libdrm. If the unichrome driver gets rewritten (or I
eventually get time), then it'll come back.
ok matthieu@
light of day and has already been removed in mesa master (ages ago).
As a bonus, removes the annoying "falling back to classic" message on
launching a gl application.
ok matthieu@.
from this was removed from the kernel and is very much deprecated.
Pageflipping is also probably broken and should not be used. Similar
change happened in mesa master a while back.
ok matthieu@
really don't need it. There's one case where it's used, and that is on
``older'' drms, newer ones provide that one value via a parameter.
This is the first stage in my project to stop all cards mapping
registers. This does mean that drivers that depend on this may
eventually die (tdfx, i'm looking at you!).
ok matthieu@
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@.
