> > 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.
I still tend to think that offscreen memory is busted on mode
switches...
Now, I agree that cutting the vram in half, and reserving both halves
to the "offscreen" needs to each head may help avoiding mode switch on
one head busting things used by whoever works on the second head, but
I'm not sure that fits the DRM needs very well..
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_id=6595&alloc_id=14396&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
