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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel