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

[Victor Lowther]

On Tue, 2008-09-16 at 19:42 +0200, Stefan Seyfried wrote:
> Victor Lowther wrote:
> > On Tue, 2008-09-16 at 11:34 +0200, Tim Dijkstra wrote:
> 
> >> We could also just drop 99video and just use s2ram that would be much
> >> easier in maintaining. ;)
> > 
> > well, my experience suggests the opposite. Right now s2ram will die
> > horribly on systems running opensource nv drivers on nvidia g80 class
> > hardware, because it requires special handling that HAL and pm-utils
> > take into account,
> 
> How so?
> seife at stoetzler:~/projects/powermanagement/pm-utils> grep -r video.rom .
> ./pm/sleep.d/99video:   local rom="/var/run/video.rom"
> 
> The file is never created, so pm-utils does nothing else than s2ram, since the
> file is never created it will not use it.
> 
> If I knew where the magic video.rom file comes from, the support in s2ram
> would be pretty trivial to do.

It is (supposedly) created at boot time and captures the contents of the
video ROM at that time.  It is needed to work around ugly suspend/resume
issues with G80 and later nvidia chipsets using the opensource nv driver
-- supposedly reposting using the saved BIOS (not the one on the card
after resume) is the only quirk that will work with them.

Matthew can fill you in on the ugly details -- I added support in
pm-utils for this back in May, and he released vbetool 1.1 at the same
time.

> >>> 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.
> 
> The whitelist in s2ram will die sooner or later (actually if I had time, it
> would probably be already gone). However, it will still provide an easy,
> failsafe and fast method to do all the quirks in one place, without lots of
> dependencies etc. But that's for the users to decide which way they want to
> use it.

Right, I understand that.  However, any system that has pm-utils already
installed will have 99video and all the dependencies it entails (unless
they perform major surgery), so why should I prefer the quirk-handling
functionality in s2ram/s2both over 99video?

Using Debian as an example, once the whitelist in s2ram is gone it is a
dependency on  hal + uswsusp vs. a dependency on hal + vbetool +
radeontool, and neither choice leads to mounds of bloat -- hal and
hal-info are by far larger packages, and (in Debian land, at least),
uswsusp is 3 - 5 times larger than vbetool and radeontool combined.

Stripping the quirk handling out of the uswsusp tools and letting
pm-utils handle things would probably be neutral in terms of space,
simplify the code you have to track and maintain, and let uswsusp focus
on making hibernate more convienent and useful (mabye even catching up
to what tuxonice can do, like saving the page cache so that the system
is not laggy for minutes after thaw ;)

-- 
Victor Lowther
Ubuntu Certified Professional