On Wed, Feb 13, 2008 at 06:44:43PM +0100, Michael Biebl wrote: > 2008/2/13, Victor Lowther <[EMAIL PROTECTED]>: > > Mostly because right now I am submitting patches for pm-utils, so I will > > favor the approach it currently uses instead in relying on yet another > > external package. > > It wouldn't be *another* dependency but a replacement for radeontools > *and* vbetools (so actually less dependencies)
Fair enough. > > We cannot get rid of the dependence on vbetools > > because tuxonice relies on it for all three sleep methods. > > This is a valid point. s2ram should have a command line option (like > --save-only/--restore), so it would be usable together with tuxonice. And when s2ram actually has that level of support built-in, we can add support for it and recommend that everyone else use it. Until then, though, the current methods will continue to work, and removing them would not really be appropriate. > > > Imho using s2ram (with the quirks provided by hal, and optionally > > > fallback to the builtin whitelist) seems like a good solution. > > > > If a given distro wants to do that, fine. I have made it easier > > for them to do so. With the modular sleep method patches, distros do > > not have to patch the core pm-utils functionality to do just what you > > propose -- just replace the uswsusp module with the one you want and > > delete the (20|99)video sleep hooks. > > > > I think that adding logic into pm-utils to handle s2ram or s2both > > as a special case in our video quirk handling complexifies the current > > video handling needlessly, when all the end-user or distro. > > I don't think that using s2ram would realy make it that more complex, > actually, as it would replace vbetools/radeontools, it would make it > simpler. Not really -- most of the complexity in the current video hooks is due to parsing the options from HAL and accounting for user overrides, and making user overrides easy overwhelmingly more important to me than what method we actually use to run the quirks, and here is why: My system is a Dell Latitude D820 with the nvidia 7400 go. They also shipped with intergrated Intel video. You cannot tell the difference looking just at system model and BIOS revision. In my system, the default whitelist applies the wrong quirks every time and without overriding the whitelist supplied settings my system will die on resume every time when the card gets POSTed. Submitting a whitelist update would be guaranteed to break other systems in the field, because the whitelist does not look at what video card the system is actually using, which (these days) is the single biggest source of suspend/resume glitches. The same holds true for any portable system that can be purchased with different models of video card. I would prefer a whitelist that actually looks at the installed video card(s) and the driver(s) those cards are using before applying quirks. Without fixing that flaw, arguing the benefits of using s2ram vs. vbetool to run quirk workarounds is a waste of electrons from my perspective. > Cheers, > Michael > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? -- Victor Lowther Ubuntu Certified Professional _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
