[Pm-utils] [PATCH 1/2] Enable autodetection and stacking of sleep methods.
seife at suse.de
Tue Sep 16 13:01:10 PDT 2008
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
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!
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)
More information about the Pm-utils