On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä 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.
And we don't know if all HW would support it anyway. > > > We are thinking with the "new model" in mind, and so far, a mode setting > > > is under control of the framebuffer. Content of video memory (framebuffer, > > > textures, overlay, whatever) simply cannot be considered as preserved > > > accross mode switches. > > > > > > We can't also block all evolutions just because we have to support a > > > broken model. > > > > I'm not suggesting that, but I do think that tying together mode > > switching and memory allocation would be a big mistake. > > Indeed. The main issue hwoever, is access arbitration. I'd appreciate your DirectFB point of view on these things. 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
