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