On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2005-03-14 at 11:20 -0500, Michel DÃnzer wrote: > > On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote: > > > On Sun, 2005-03-13 at 23:28 -0500, Michel DÃnzer wrote: > > > > On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote: > > > > > > > > > > And finally, I want to blank the screen (using the accel engine) > > > > > before > > > > > setting the new mode, so that we come out "clean" of the mode setting > > > > > (without ugly artifact), and I will probably clean both fb's > > > > > (simpler). > > > > > > > > That would break X with UseFBDev. > > > > > > How so ? > > > > X assumes that the framebuffer (as in video RAM) contents are preserved > > on mode switches. > > Which I consider bogus :) Oh well... does it do a lot of other crappy > assumptions like that ? What if I just can't allocate it and decide to > put it elsewhere in vram ? (unlikely with my current scheme but > possible). X needs to be fixed.
Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. -- 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
