On Fri, 1 Feb 2002, Kevin E Martin wrote:
> On Wed, Jan 30, 2002 at 10:43:20PM -0500, Vladimir Dergachev wrote:
> >
> >
> > On Wed, 30 Jan 2002, Jens Owen wrote:
> >
> > > Vladimir Dergachev wrote:
> > >
> > > > Also, I can make drm driver work nice with older 2d drivers - as soon as
> > > > someone will show me a way to tell the version of the 2d driver that is
> > > > accessing the drm driver.
> > >
> > > How about using a new set of IOCTL numbers for the new interface--then
> > > you'll know whether you have an old or new driver accessing it.
> > >
> >
> > Jens, it is not a new interface. It is simply a matter of moving AGP and
> > framebuffer apertures within cards internal address space. If it is moved
> > the buffers (texture, ring buffer, indirect, etc) need to have their
> > addresses adjusted. (that was the place where documentation was wrong..
> > it named those fields as "offsets" but they are absolute addresses). Once
> > it is setup and the buffer addresses are ok everything goes in as before.
> > But if any component gets the wrong idea and tells the card "go get a texture
> > from the wrong place" it all locks up.
> >
> > To reiterate it is simply a matter of initializing the card.
> >
> > The problem arises from the fact that initialization is done both in 2d
> > driver and drm driver. DRM initializes the ring buffer and 2d driver sets up
> > framebuffer and passes down various buffers - texture, stencil, depth,
> > etc. If either is wrong lockup results.
>
> Vladimir,
>
> I know what you're talking about with respect to the initialization;
> however, the problem that Jens and others are trying to point out is
> that we must keep backwards compatibility. Let's see if I can explain
> what is going on here:
>
> Assumptions:
>
> - The current XFree86 4.2.0 drivers have been released (let's call these
> DDX version x)
> - The Linux kernel currently has DRM drivers (or soon will have) that
> work with DDX version x (let's call these DRM version y)
>
> IIRC, the rule that we worked out with Linus is:
>
> - If we want to update the DRM drivers in the Linux kernel to say DRM
> version y', which supports the new XFree86 4.3.0 drivers (DDX version
> x'), then DRM version y' MUST also support the older DDX version x
> drivers as well for backwards compatibility.
That's too bad because this will imply a _lot_ of hair in the drivers.
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"
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.
Furthemore, I don't know about you, but I really dislike the idea of
having _two_ XFree trees just for the purpose of testing.. And I certainly
won't be able to test compatibility with older versions as thoroughly.
So, it is possible to make this change work, but I do not see this worth
it in the end.
Vladimir Dergachev
>
> One way that this can be accomplished is by adding new IOCTLs for those
> entry points that have new functionality or slightly modified and
> non-backwards compatible functionality. For example, if the current
> IOCTL assumes that the framebuffer start address is at 0, and instead
> you need an IOCTL to read the FB start addr from a variable passed in
> (or from the SAREA), then in the new DRM driver, you need to have two
> IOCTLs: the first IOCTL is the same as the one in the old DRM driver,
> which assumes that the FB start addr is at 0; and, the second IOCTL is
> the one that reads it from a variable. The underlying code in the new
> DRM driver can be modified so that almost all of it is shared between
> the two IOCTLs; however, we still need both entry points so that we
> maintain backwards compatibility.
>
> I hope this explanation helps. Please correct me if I've misinterpreted
> the rule. I'm trying to put it in it's simplest terms so as to minimize
> confusion.
>
> Kevin
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
