update mesa.
Specifically, we disallow in radeondrm for dri clients mapping
registers, so don't try and map them (and thus fail as we currently
were). for r300+ this was only used for falling back on old drm versions
(doesn't matter). For r100, the new BO abstraction used the SWI number
(in hardware scratch reg 3) for the buffer age, so use the newly added
getparam member to grab that info instead of trying to read the mapped
registers.
Update to the lastest kernel headers before you even think about
building this or trying to use a snapshot on r100/r200.
So now radeon works with mesa again, hoorah!
Tested on rv250 by Josh Elsasser, and on R420 (and x800) by myself.
changes from later intel versions (after the UMS removal). 95% of this
is the xvmc reworks that makes that code even halfway sane. xvmc is now
enabled by default on 965+.
Tested by many on tech@, thanks!
ok matthieu@
While this feature at best can save 05w idle power, it is very flakey. Disabling
it fixes (or at the least masks) the problem that some 915 and 945 users were
seeing where they ended up with a blank screen (it turns out that no problems
fired because everything was still working, just FBC screwed up and never
actually scanned out the framebuffer).
As some examples for reliability linux with kms has disabled fbc on these
chipsets due to some unreliability issues (especially over suspend). and the
window driver apparently also does not used it.
Tested by kettenis@, Tom Murphy, edd@ and myself.
ok matthieu@
These files were missing from the last commit. (due to shuffling the cvs
diff between old driver and new one was 155246 lines, so two files isn't
that bad...)
