On Fri, 5 Mar 2010, Alan Cox wrote:
> > So the watershed moment was _never_ the "Linus merged it". The watershed > > moment was always "Fedora started shipping it". That's when the problems > > with a standard upstream kernel started. > > > > Why is that so hard for people to understand? > > So why are you screaming at the DRM and Nouveau people about the > breakage ? That's the bit I really don't understand. Umm. You _really_ haven't been following, have you? Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. And I would like to say that yes, Dave really helped me. He got me a working setup again. I thank you, Dave. It means I don't have to revert the thing, and we can hopefully make progress. That said, I do think that the Fedora people _should_ have been the ones to catch this as a problem, and pushed back a bit on the Nouveau people even before it got to me. For all the reasons I've mentioned. Even if you need to change the interface, I've actually looked at the patch in question (have you, Alan?), and I got the very strong feeling that it _could_ have been done without breaking compatibility so completely and utterly, and making it so apparently intentionally hard to have a driver that can handle both the old and the new. IOW, maybe it would have required a new nouveau_drv etc, but with a slightly less hack-and-slash approach, maybe the new one could have supported the old interfaces enough to at least limp along. For example, breaking DRM so that 3D doesn't work, but you still get basic 2D acceleration - that's _way_ more acceptable, and is likely to need a much smaller subset of the whole DRI functionality. It looks like nobody even tried. Linus ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel