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

[Ville Syrjälä]

On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
> > If radeonfb will allocate the buffer for the second head from the top of 
> > the memory users would basically have to guess it's location. matroxfb 
> > simply cuts the memory in two pieces and allocates the buffers from the 
> > start of each piece. I don't really like that approach. Adding a simple 
> > byte_offset field to fb_var_screeninfo would solve the problem quite 
> > nicely but I don't know if such API changes are acceptable at this stage.
> 
> You wouldn't have to guess its location, look at fix.smem_start.

But how would someone mmap() the whole memory then? matroxfb already plays 
tricks on fix.smem_start on Millennium I/II cards and it really confuses 
DirectFB's memory allocator.

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

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/