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