On Fri, 2006-11-03 at 12:34 -0500, David Zeuthen wrote: > On Fri, 2006-11-03 at 17:21 +0000, Richard Hughes wrote: > > > - For Suspend() let HAL capture the output of the tool being invoked > > > to a file /var/lib/hal/suspend-output > > > > you mean have pm-suspend quit with exit code 3 and report "Device failed > > to sync" as an example? > > Yea. That would just be in the output. To figure this out you would need > to look at the debug output through SuspendGetLastError(). Which is > fine, there's nothing any program can do about it.
Yes, indeed. > > > - Provide a new method "void SuspendClearLastError()". It will > > > delete the file /var/lib/hal/suspend-output > > > > Ick. What's wrong with just deleting this file the next time we do a > > system action like shutting down, suspending, hibernating etc? If we > > didn't fail, then the file won't exist. > > What if the video doesn't come back and the user presses the Power > button in despair? Then we lose the file... I never thought of this. > > > This is to be called by the desktop policy manager (e.g. g-p-m) once > > > we know that the system is back in a workable state. How does this > > > work? g-p-m should call this when the session is unlocked since > > > this is evidence that the user can use his system. In the event > > > where the session is not locked... I don't know.. perhaps after > > > 5 minutes or when g-p-m terminates? > > > > Seems a bit messy to me. > > No, it's just as soon as we figure out that the system is usable... we > clear the error... it's not nice, I agree, but really some systems where > video don't resume are technically usable. The only thing we can do is > to wait for what looks like intelligent input from the user... e.g. him > unlocking his session should be good enough. > > If we don't this we get false positives. Suppose that I suspend, then > resume and then leave my laptop to run dry. Then the next time I boot I > get a "resume failed!" error which is bogus. Sure, agree. > Of course in the normal situation it's good enough to just clear the > file when g-p-m terminates but it's not ideal. I don't see what the big > problem is; just call SuspendClearLastError() whenever g-p-m says the > session is unlocked? Easy to implement in the current code. > > > (OK, so only the first user to login after suspend gets to see the > > > error. I think that's OK.) > > > > Not if you autoclear that on shutdown, next suspend or hibernate. > > I think I already said that the desktop policy manager clears the file > when it terminates so this is the same. I'm just proposing to cut false > positives; it's not a big deal really, I can live without g-p-m calling > SuspendClearLastError() when a session is unlocked, I just think it > makes the system more robust. What do you think? Ohh I agree, we should clear it when the user is doing stuff for sure. When the stuff hits HAL CVS, I'll add support into g-p-m. Richard. _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
