> It's ugly, but that's not the point. The point is that all deployed > versions of X (and even current X.org CVS head still, in fact) make this > assumption.
Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. We simply cannot guarantee preserving the video memory accross mode switches. We have enumerated enough examples of that, and Ville himself came up with a nice one about Matrox. What we _can_ do is let people know what was expelled from video memory eventually. But even the "let's ask fdbev what will change" before the actual mode switch isn't really a good idea in the long run since it sort-of defeats the purpose of having a common memory manager. 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
