Wild and crazy times for the development tree

[Mike A. Harris]

Dave Jones wrote:
> On Mon, Mar 20, 2006 at 04:49:42PM -0500, Mike A. Harris wrote:
>  > So, R300 dri support will be something you need to compile for yourself
>  > for the time being if desired.  Also, our kernel does not have the
>  > R300+ PCI IDs in it anymore, so you may need to recompile your kernel
>  > as well.  Not sure what davej's specific plans are for that, but I hope
>  > he keeps the R300 PCI IDs out of the kernel at least until the r300
>  > DRI driver is remotely useable large-scale.
> 
> not that it seems to matter. X seems to be doing a 'modprobe radeon'
> when it sees anything ATI.

Yeah.  Not sure when exactly that changed, but it's probably because
there is now OSS support for Mach64/R128/Radeon for 3D I'm guessing.
We don't ship the mach64 DRI driver, or the R300+ one, but the X
server still seems to have static lists of stuff which is a bit brain
dead if you ask me.  ;o)


> Chopping the IDs out stops it being
> initialised, but it appears that X does _something_ differently
> just by having the module loaded even if its not using it.

Indeed, it is looking that way.  We'll likely figure that out during
FC6 and hopefully get it fixed in Xorg 7.1

> I can keep them chopped out for the time being, but the downside is
> we're not going to get a lot of coverage testing, so how will we know
> when its 'good enough' ?

I'd say at a minimum - when there's a new upstream release which
contains CVS checkins to the code in question as a minimum.  If
no fixes have went into the code that didn't work before, it's
most likely still broken.  ;o)

For the 2D-only side of things, I'd want to wait at least until
the new 2D radeon driver comes out (stable branch) and let it
get tested for a while in rawhide.  Then hopefully get any new
regressions resolved.  After that, enabling the kernel side
again to see if it breaks anything would be following scientific
method.  I'd prefer to avoid re-enabling 2-3 things simultaneously,
and then trying to guess which one caused breakage to occur though.

By the time a new stable 2D driver has come out and had a reasonable
shakedown period, then have a kernel DRM update which re-enables the
kernel bits, and another shakedown period - a new Mesa is likely
to be out, if not for the 6.4.x track, then the 6.5.x/6.6 track
heading towards Xorg 7.1.  I think it'd be good to wait until then
before considering re-enabling R300 DRI driver support in Mesa, as
we'd just be enabling known-broken code to do it before then, and
getting nothing useful other than an increase in bug reports
hitting Red Hat bugzilla, which should go to X.Org bugzilla instead.
;o)




-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.