> 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.

> 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.

-- Gareth

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to