On Tue, 01 Mar 2005 01:09:28 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Tue, 2005-03-01 at 17:02 +1100, Benjamin Herrenschmidt wrote: > > On Mon, 2005-02-28 at 15:09 -0500, Michel Dänzer wrote: > > > On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote: > > > > > > > > I think long term though, a better solution would be to get rid of > > > > mergedfb and handle each head separately but just change the 2d/3d > > > > engines offsets depending on which head you are rendering to. then > > > > you wouldn't have to worry about the limits so much (although some of > > > > these new super hi-res LCDs would still need some work). > > > > > > Yep, and as a bonus you'll have to solve basically all of the issues of > > > multi-card Xinerama. If there's a benefit to that (other than making the > > > exotic multi-card Xinerama possible or at least easier), I'm afraid I > > > don't see it. Fixing the remaining MergedFB issues seems much easier and > > > more useful to me. > > > > Hrm... I tend to disagree :) MergedFB is a hack imho. It's much saner in > > the long run to fix the issues of multi-card Xinerama. > > I agree that would be nice, but I honestly don't see any benefit it > would offer over MergedFB in the single card case. What am I missing? >
mergedfb has the following problems: - 3d engine is limited to 2048x2048 - tiled surfaces are limited to a width of 2048 - framebuffers have to be rectangular, so using dissimilar modes on each output cause viewport scrolling which users hate. - xinerama is supported by a driver specific xinerama extension, which doesn't work with the real xinerama extention. Other than that mergedfb serves it purpose as in interim solution for dualhead with 3d. We could solve these problems for mergedfb, it may even make sense to in the short term, but I'd rather do it the right way in the long run. long run in this case being whatever the new X/graphics server/driver ends up being: drm/fb combo or whatever. while we are on the topic it'd be nice to handle all outputs and framebuffers on a card within one instance of the driver. The way X does it now with the loading twice complicates the output handling. Alex > > -- > Earthling Michel Dänzer | Debian (powerpc), X and DRI developer > Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer > ------------------------------------------------------- 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
