On Mon, 2005-02-21 at 16:11 -0500, Alex Deucher wrote: > If we are going to start "fresh" so to speak, why even mess with > mergedfb in the new fb/drm driver? it would make more sense to just > update the 2d and 3d engine offsets to point to whichever framebuffer > is "active." for dualhead the offset would just be updated along with > the other 3d state just like with multiple 3d apps. We could also use > separate tiled surfaces for each frambuffer so we wouldn't be limited > to 2kx2k. Then we wouldn't have any of the limitations of mergedfb.
I totally agreed. In fact, we had this discussion about mergedfb "issues" with friends here yesterday and came to the conclusion that it was a nice hack, but not something we want to stick with eternally. We still need a good allocator for video memory though ;) When talking about which framebuffer are "tied" together, I meant a clean way for userland clients to know which /dev/fb's form a "pair" on a given card (for access arbitration/discipline issues) and properly map /dev/fb'd to DRI device nodes (since we probably want to keep the existing separate ioctl APIs for backward compatibility at least, just build on top of it). 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
