Re: [PATCH 2/2] Fix console handling during suspend/resume

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

> X and video really isn't anything special. They are just the _obvious_ 
> problem. They are the problem that you can't avoid on _any_ machine: the 
> others you can just add special cases for on a one-by-one basis, and you 
> can get most setups working.

X is a bit special in fact in the sense that if you want something
reliable, including the ability you mentioned to be able to reconstruct
state on resume (because your state "saving", gosh, I don't like that
terminology, we aren't really saving a sate there) didn't stop
operations, you'll have to push whole new concepts all the way up the
stack... to things like X APIs, GL/DRI, etc...

For example, X can store pixmaps in vram. It needs to know the vram is
going away to migrate them back into main memory (or other storage).
Thus if we want to separate thing, we have to create new intefaces to X
so it gets a chance to do that (and fallback to a boring drawing mode
maybe until suspend) since I don't think you can just tell an X client
that a pixmap it owned just vanished.

Worse with GL. Clients store textures, fbo's (framebuffer objects),
etc... in vram and there is no GL interfaces to tell GL apps to bring
their stuff back in as the vram might become invalidated.

And that's just the tip of the X iceberg.

Thus it's definitely worth considering X as a special case for now (and
other gfx applications) and using the existing method of taking away the
VT from them is what will give us the best chances of not shooting
ourselves in the foot, at least for now. X might do things like
enable/disable AGP, which affects the config space (and thus even your
saved states if that makes any sense), etc... let's just not open that
can of worms right now :)

Ben.