On Wed, Mar 16, 2005 at 10:50:52AM +1100, Benjamin Herrenschmidt wrote: > 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,
There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. matroxfb deals with that by moving the buffer and changing smem_start and smem_len appropriately. But that is really bad for DirectFB's offscreen memory management. After a mode switch the memory manager would need to know what kind of initial byte offset was used. Of couse it would be possible to determine that from smem_start by knowing how the aperture must be aligned. Actually we already do that sort of thing to allow hw accelerated rendering when used on matroxfb controlled G450/G450/G550 CRTC2. But in that case the offset won't change on mode switch. > 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). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. -- 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
