Re: [Linux-fbdev-devel] [PATCH] Fix switch from XFree

[Sven L. <sve...@wa...>]

On Tue, Feb 10, 2004 at 10:17:21PM +1100, Benjamin Herrenschmidt wrote:
> 
> > 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 :)

Well, i have no problem in fixing XFree86. But then, one would have to
consider the alternate or outdated servers too, altough i doubt you care
about XiG or other such comercial servers which provide x86 only.

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

Or to use a different pipe, if the hardware provides accelerated context
switching :)).

> > 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

Ok.

> > 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).

Ok, but for the mode, if you use UseFBdev, then the server will not
touch the mode, and rather use the underlying fbdev infrastructure for
it. Why not do something similar for 2D, and tell X that this version of
the fbdev does indeed know how to fix the accel engine, and doesn't care
about getting it in broken state.

> > 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.

Ok, i understand, but again, maybe if the fbdev doesn't care, there is
no need for X trying to save/restore it ? Or whatever it tries to do.

I think we could decide on a sane policy for both fbdev and X to follow
(for example, each one is in charge of resetting their mode/accel engine
state), and then submit this policy to the XFree86 people to adhere too
if the UseFBDev option is used. If XFree86 drivers do not implement it,
then they are broken, and its their problem, but if they do, then we
result in having the most economical context swithc possible.

Friendly,

Sven Luther