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. 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 _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
