[RFC] X Display Failures in Suspend and Resume

[Jim Lieb]

On Monday 10 November 2008 17:25:24 Matthew Garrett wrote:
> On Fri, Nov 07, 2008 at 01:47:48PM -0800, Jim Lieb wrote:
> > Pete asked me to look into the suspend/resume failures and report back on
> > what is going on to cause X to fail on some notebook/laptop machines. 
> > The attached pdf is a relatively final draft of the report including a
> > proposal for fixing the problem.
>
> Are you sure this diagnosis is correct? The resume from hibernation case
> is made rather more "interesting" due to usplash also being involved,
> but the suspend to RAM case is no more inherently racy than the normal
> VT switching case. Not having video on resume from RAM will generally be
> down to the kernel failing to restore graphical state, something it can
> currently only do for Intel hardware[1]. The userspace workarounds for
> reinitialising the graphics are certainly not guaranteed to work
> reliably.
I've not gone into the details of the hibernation case.  The issues that I
was originally looking into was a combination of the server not resuming
properly and some other desktop apps not resuming either because they
got lost in a VT_WAITACTIVE.  The end result is the same, races.  The 
mix of suspend/resume (or hibernate/resume) into this mix just makes it
worse.

There are some scenarios that have nothing to do with suspend/resume
that also break.  F9 had similar problems switching from the boot X server
from what I've read.
>
> [1] Though there are still a few bugs there, which can result in failure
> even on hardware that /should/ be working
As for the Intel hw vs. the rest of the video designs, I can't really answer.
I know of one Intel driver that has problems.
> --
> Matthew Garrett | mjg59 at srcf.ucam.org
Thanks for your comments.  Do you think the design is a) workable and
b) worth the work to shift to it?  Our goal here is to make this problem
"go away" by cleaning up the API races.

Thanks again

Jim
-- 
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.