On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:

On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:

quoted

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@sci.fi
http://www.sci.fi/~syrjala/