[Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

[Benjamin Herrenschmidt]

> > I once did a similar thing for an embedded prototype: take a fixed amount of
> > memory for both frame buffers (this was a UMA system), fb0 starts from the top,
> > fb1 starts from the bottom. You can enlarge each frame buffer, until you read
> > the memory of the other. Each fix.smem_{start,len} corresponds exactly to the
> > memory allocated to each frame buffer.
> > 
> > Of course, if you also want off-screen memory (i.e. memory beyond
> > xres_virtual*yres_virtual*bpp/8), things get more complicated, since currently
> > there's no way for the application to ask for a minimum amount of off-screen
> > memory. Perhaps a new field in fb_var_screeninfo (and zero means `I don't
> > care', for backwards compatibility).
> 
> Offscreen memory is pretty much essential for DirectFB.

I still tend to think that offscreen memory is busted on mode
switches...

Now, I agree that cutting the vram in half, and reserving  both halves
to the "offscreen" needs to each head may help avoiding mode switch on
one head busting things used by whoever works on the second head, but
I'm not sure that fits the DRM needs very well..


Ben.