On Fri, Jun 30, 2006 at 11:14:05PM +0200, Pavel Machek wrote: > Hi! > > I think s2ram can get info from HAL easier than HAL from s2ram, but I'm > > biased :- > > Design criteria: It has to work on machine without gnome/hal/etc, > because I do not use that stuff.
But one could argue that in that case, something like #!/bin/sh exec /usr/sbin/s2ram -f -s -p somewhere in your $PATH to save you from always typing your options will work fine for debugging also. In the real world, on machines that are actually supported by s2ram and friends, HAL will be running on >90% of the installations. And i am pretty sure it would be trivial to write a "hal-show-me-the-s2ram-options" script that retrieves those options for you on this unknown machine :-) > (And running windows system to get > s2ram running is going to really hurt debugging, I need people > suspending from single user mode). Again, even if i do not like it, but there are machines that just do not turn on the light with vbetool / anything, but the X server does. And some of them even only with the NVidia driver. Of course we should fix them (and as you might have noticed, i am pretty strict about just accepting whitelist entries, where suspend without X actually was tested), but for now, suspend might just work for people with X when it does not with console. Another example: i have a nasty ACER tablet here that needs VBE_SAVE on console, but only if X is not running. If X is running, you might not do anything or it will livelock somewhere (X will take up 100% CPU until reboot). I do not really want to express this in terms of s2ram whitelist entries... :-) Of course most of this are kernel / X / BIOS bugs, but the whole point of s2ram is "we work around known bugs of some crappy piece of software". > > > Right now, there is no problem in co-existing, the pm-utils scripts just > > > need > > > to call s2ram with "-f" which disables the internal whitelist, then "-a > > > [123]" > > > for s3_bios/s3_mode, "-p" for "vbetool post" and "-s" for "vbestate save / > > > restore". I will probably add another switch for "vbetool vbemode get / > > > set" > > > in s2ram and also for "vbetool dpms off/on". > > > The only thing is, that in s2ram, the workarounds come in "pairs": if it > > > does > > > "vbestate save" before suspend, it will do "vbestate restore" after > > > resume, > > > before returning. I believe that this is the right thing to do and even > > > important in order to get the restore as quickly done as possible, without > > > the possibility that the user presses ALT-f7 and screws up everything > > > because > > > the card was not reinitialized soon enough.. > > > > Whats wrong with HAL doing the vbestate stuff? That's what I've put in > > HAL CVS with the SuspendVideo method. You need external storage which might not be accessible at the time you resume... You add lots of external dependencies. Video will be switched on sooner, so you actually see what fails. The race window during resume when the user might press ALT-F7 gets shorter. > Besides impossibility to implement s2both that way? No chance to > pagelock it so you get working video even when your SATA resume fails? Exactly. -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
