On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:
I added Keith's proposed struct with int64_t as the value, and I added '#include <inttypes.h>' to xf86drmCompat.c. Everything compiled fine.
Easy enough. :)
I've updated http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff, addressing the feedback I've received so far - thanks, more appreciated as always. In particular, Eric will need to double check this for the BSDs; I don't know what to define DRM_PUT_USER_UNCHECKED() to, and the filp_priv handling may still be wrong.
I briefly looked at the patch. That looks fine to me.
Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway.
FWIW (not much :), I'm not aware of such problems. Do you mean the opposite problems of newer radeon 3D drivers with older DRMs?
Right. My memory is a bit fuzzy, but I could have sworn that there were some problems with very old (i.e., 4.0.x) 3D drivers with some of the newer kernel modules.
That aside, I think we should be able to remove xf86drmCompat.c now. Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If that's the case, and all of the client-side drivers have been updated to not use the functions in xf86drmCompat.c, why do we need it? I looked at the mga driver with nm, and it doesn't reference any of the drmMGA* symbols.
------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
