Solo Xgl..

[Benjamin Herrenschmidt]

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.