[Pm-utils] [PATCH 1/2] Enable autodetection and stacking of sleep methods.

[Victor Lowther]

On Wed, 2008-09-10 at 22:10 +0200, Danny Kukawka wrote:
> On Dienstag, 9. September 2008, Victor Lowther wrote:
> > On Tue, 2008-09-09 at 11:24 +0200, Tim Dijkstra wrote:
> > > Victor Lowther schreef:
> > > > I also trimmed s2ram from uswsusp -- we just fall back to kernel
> > > > suspend instead.  This way, we only have to handle video quirks in one
> > > > place, and we control that place.
> > >
> > > So you are basically removing uswsusp support? That would be very
> > > unfortunate, than we will have to add our own patches again...
> >
> > Just s2ram.  Handling quirks in s2ram and in 99video was just annoying,
> > but with the recent "interesting" behaviour of the nvidia g80/g90 chips
> > and their habit of only coming back from suspend if you posted from a
> > saved copy of the BIOS, s2ram was causing resume failures that 99video
> > handles correctly, so the old "disable 99video in favor of handling the
> > quirks in uswsusp" bahaviour missed this case when running with s2ram.
> 
> That's not really a reason to drop s2ram support. There are good reasons, 
> without starting any old discussion again, to use s2ram instead of 99video. 

Well, I never found any of those reasons convincing -- s2ram has its
internal whitelist and it is a single executable, but those are not
compelling reasons to me.  If there is something beyond those, I am
willing to be enlightened.

> If you don't have s2ram (which you obviously do), you have no trouble. And for 
> the rest, which want to use s2ram, they should report it to the s2ram 
> maintainers. But this isn't your problem at all. You make it only complicated 
> for all these users. They have to revert your patch ....

My main issue is maintenance related -- pm-utils has to force s2ram to
do what 99video would do as well in order to handle the quirks that HAL
asks us to. From a maintenance standpoint, that buys me nothing but
maintaining two different mechanisms to handle quirks where one would do
the job.  If it cost nothing to maintain compatibility with s2ram (say,
by making it take the same commandline parameters that hal passes and
having it on a release schedule), it might be another matter, but right
now the easiest way for me to deal with s2ram is to treat it as nothing
but another mechanism to echo mem > /sys/power/state, and we already
handle that part normally. 

> > While I suppose I could set up some sort of framework where certian
> > quirks are handled by s2ram and certian others are handled by 99video,
> > that seems like a recipie for disaster.
> >
> > s2disk and s2both are still supported by this patch series, and now we
> > force s2both to run quirkless.  I could have s2ram do the same thing,
> > but since all it ends up doing the same as what we already do, it is
> > just as easy to fall back to the kernel method.
> 
> That all is easy to say if you don't use s2ram. And not everyone is doing what 
> you do. 

Right.  And once pci_state and no_fb support is merged, there will be no
functional difference between 99video and s2ram, except that s2ram has
an internal whitelist that pm-utils ignores by design in favor of the
quirks that HAL gives us.

> Danny
> _______________________________________________
> Pm-utils mailing list
> Pm-utils at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pm-utils
-- 
Victor Lowther
Ubuntu Certified Professional