On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote: > On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote: > > 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 > > This is multi-head, right? That implies one fb per head. So, can't you do > separate mmaps? fb0->fix.smem_start|len and fb1->fix.smem_start|len.
Sure, re-read the thread :) Also, he's worried about management of offscreen memory. (which is an issue too because of possible problems with the setup of the apertures -> start of the discussion, and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Ben. ------------------------------------------------------- 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
