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) _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
