From: Ian R. <id...@us...> - 2003-10-27 20:01:03
|
Michel D=C3=A4nzer wrote: > On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:=20 >=20 >>I added Keith's proposed struct with int64_t as the value, and I added=20 >>'#include <inttypes.h>' to xf86drmCompat.c. Everything compiled fine. >=20 > Easy enough. :) >=20 > 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=20 >>seem to remember there being problems with the really old client-side=20 >>drivers and the newer kernel modules anyway. >=20 > 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=20 some problems with very old (i.e., 4.0.x) 3D drivers with some of the=20 newer kernel modules. That aside, I think we should be able to remove xf86drmCompat.c now.=20 Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so.=20 If that's the case, and all of the client-side drivers have been updated=20 to not use the functions in xf86drmCompat.c, why do we need it? I=20 looked at the mga driver with nm, and it doesn't reference any of the=20 drmMGA* symbols. |