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�
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
