Re: [PATCH] Fix switch from XFree

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Mmm, i wonder about this. The X driver is supposed to be responsible for
> saving and reseting the engine when leaving/entering. This is usually
> done in a separate way when using or not using fbdev.

This is a nice dream. It's both _very_ impractical (you can't always
_read_ the engine state) and usually buggy as hell (and go fix XFree :)

On the other hand, it's very simple for the driver to just reset &
restore the engine state it expects.

> Now, if we are going to save/restore the contect too, then this would
> mean a risk of dual saving the engine state. Or maybe the X server
> doesn't really save the context, but just reinitialize it when entering.

It tries too for the mode... but fails. It doesn't try for the engine

> I have the feeling that more working together would be helpfull, or
> maybe setup a proper policy for X/fbdev to handle this properly.

I don't think it's reasonable to expect the XFree driver to save/restore
the accel engine state. It's already quite broken with the mode on
radeonfb (the VGA stuff seem to do bad things on PPC at least).

> Maybe the fbdev driver could set a flag or something, which would tell
> the X server that it is taking charge of saving/restoring the accel
> engine, so the X driver would not try doing this too, at least in the
> UseFBDev case (but do we care about the other case ?).

No. Trying to save/restore the engine state would mean trying to
save/restore dozens (or hundreds maybe ? depends if you count the 3D
engine too :), it makes little sense, it's much simpler for fbdev
to just reset the state it expects.

Ben.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn