> 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
