On Thu, Jul 20, 2006 at 05:32:12AM +0200, Pavel Machek wrote: > Hi! > > I'd rather say "call s2ram with the correct options" and let HAL figure > > out the correct options. > > I'd prefer HAL figure out the complex options, but still leave > "simple" whitelist inside s2ram.
Yes, that's fine with me. I will try to come up with some documentation that clearly documents this, so people know that their machine (some desktop mobo with $VENDOR graphics card) will probably not make it into s2ram whitelist, but they can whitelist it via HAL. It also makes it easier for me to say "machine does resume from within X is no reason to put it into s2ram whitelist, go for the HAL whitelist instead" :-) > > We can just limit the amount of machines supported by "plain" s2ram to > > those we can easily match against, but then we can probably also just > > stick to the current whitelist format. > > Yep. Simple :). > > > Distributions will, however, just use HAL to match the machines and call > > "s2ram -f $HAL_S2RAM_OPTIONS" from some HAL helper. > > I guess that we can work with distros and keep "simple" whitelist > entries in s2ram... We can probably even extract those from the fdi-files, we just skip those with "advanced" matching rules. -- Stefan Seyfried | "Please, just tell people QA / R&D Team Mobile Devices | to use KDE." SUSE LINUX Products GmbH, Nürnberg | -- Linus Torvalds ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
