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

[Stefan Seyfried]

Victor Lowther wrote:
> On Tue, 2008-09-16 at 19:42 +0200, Stefan Seyfried wrote:

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

Well, neither pm-utils nor vbetool contain an init script that would create
that file, so pm-utils can not use it. Or you depend on yet another package or
yet another undocumented hack.

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

Because it is more robust (no temporary files...) and has less runtime
dependencies (vbetool, radeontool). I'd say it is faster, too.

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

We were talking about the "uswsusp is used anyway" case. Of course, a "s2ram"
package could also be built which leaves off s2disk and s2both if that would
be wanted, but that's a different story.

Right now, you are inflicting the vbe- and radeontool dependency even on users
that have uswsusp already installed.

> 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 ;)

Let tuxonice first catch up with upstream kernel acceptance ;)
Nigel: just joking, no pun intended!

Best regards,
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)