On Fri, 1 Feb 2002, Gareth Hughes wrote:
> > That's too bad because this will imply a _lot_ of hair in the drivers.
>
> That's the way it has to be, for the DRM code to remain in the stock
> kernel distro. Linus has make this crystal clear.
>
> > The fact is that we have a driver split several ways: 3 portions from
> > XFree tree (2d, 2d and drm), capture (km, GATOS) and kernel framebuffer.
> >
> > The only right way, IMO, is to simply request that all driver versions
> > must match. Maybe it is good idea to change drm to allow driver libraries,
> > where we do not simply request radeon driver but, "radeon driver version
> > X.Y.Z"
>
> The only safe way to ensure this is to distribute the drivers (all parts)
> as a separate package. There are obviously pros and cons to doing it
> that way.
>
> > Now, I'll be the first to agree that for this particular change (memory
> > controller) we can get by with one extra IOCTL or poking in the card's
> > registers or even passing invormation in the lower bits of aperture
> > addresses MS-Windows style.
> >
> > The problem is what the code is going look like.. And the more important
> > question is: what it will look like after another change like that ?
> >
> > This memory controller patch is not the last change that would make DRM
> > incompatible with older drivers. Let me see:
> > * TV out might cause it to happen again (I don't know as this code has
> > not been written yet)
> > * 8500 3d driver might do it too.
> > * whatever ATI might come up with next.
>
> Perhaps, if we were able to start from scratch, we could come up with a
> clean way to avoid these problems. Unfortunately, a lot of the early
> design decisions were made when, quite frankly, we didn't understand
> the current -- and future -- hardware well enough.
I can't believe I am hearing this. The major benifit of free software is
that if there is a new and better design you can try it out and then
everyone can upgrade. It's not as if we are charging them money they way
Microsoft does.
Are you saying that progress stops with the inclusion of the driver into
the kernel tree ? Could it be that you misunderstood Linus and he meant:
during stable series ?
As for understanding the hardware - you can't possibly understand which
has not been released yet. Heck, with the state of things that is now,
we often don't know details about the hardware that was just released.
>
> > So, it is possible to make this change work, but I do not see this worth
> > it in the end.
>
> What you're suggesting boils down to shipping the DRI drivers (incl. the
> DRM portions) as a separete package. If you can't maintain backwards
> compatibility, this is the way it will be. End of story.
What about including both old and new drivers in the kernel simultaneously ?
And make them register the PCI ids instead of pretend they don't access
the device ? This way will have radeon_X.o for DRM modules and Xserver
will simply attempt to load the correct version (and remove wrong one if
it is loaded).
Vladimir Dergachev
>
> -- Gareth
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
