Hello. Your scripts is definitely better, thanks. One thing I can't understand: why should we run some commands in subshell and why so many sleeps (one for avoiding race between powerbutton and lid).
Well, about screen: First, I have to correct myself. Screen sometimes remains blank, sometimes it is blank with some garbage. But without framebuffer (vga=normal) and in X resuming works fine. I use 2.6.11 from Sid (because of ondemand governor absent in Sarge's 2.6.8), but all other packages are from Sarge. Video hardware: 0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) On Thu, May 12, 2005 at 11:45:49PM +1200, Andrew McMillan wrote: > On Wed, 2005-05-11 at 15:42 +0300, Alexander A. Vlasov wrote: >> Hello all. >> >> Finally, I installed Sarge on my Compaq Presario 2200, but I face >> following problem: >> laptop can be suspended-to-ram by `echo mem > /sys/power/state' (and >> suspending works fine -- led blinks slowly, display shutting down and so >> on), but it can't awake from this state. Opening lid or pressing the >> power button leads laptop to shutdown, not to resuming to normal state. >> >> Any ideas/suggestions? > > Hi, > > On some laptops I have seen that if you hold down the "Fn" key for a > second or two it will unsuspend in a manner that is not recognised as a > power button event. > > Otherwise it is necessary to add locking against recognition of the > power button event, while the suspend script is running. In another > e-mail you suggest that this would be a lock file that the > suspend/resume script would write, and that the power button script > would remove, but I wonder if a better solution would be for the > suspend/resume script to write and to remove (after resume, of > course :-) > > With a tweak like that, my own scripts would look like this. > > /etc/acpi/suspend_to_ram.sh: > ================================================== > #!/bin/sh > # /etc/acpi/suspend_to_ram.sh > # Initiates a suspend to memory [e.g. when the lid is closed] > > if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop > then > dcop --all-users ksmserver ksmserver logout 0 2 0 && exit 0 > fi > > sync > > whereami --syslog --run_from suspend2ram undocked > DISPLAY=:0.0 xscreensaver-command -lock > > logger -t "acpi-sleep" "Initiating sleep at `date`" > > touch /var/lock/suspend-resume.lock > echo mem >/sys/power/state > sleep 1 > > logger -t "acpi-sleep" "Awakening from sleep at `date` ?" > > ( > # Run in a subshell so we can finish our job... > sleep 2 > whereami --syslog --run_from resumefromram > ) 2>&1 | logger -t 'acpi-sleep' & > > sleep 1 > rm /var/lock/suspend-resume.lock > ================================================== > > > /etc/acpi/powerbtn.sh: > ================================================== > #!/bin/sh > # /etc/acpi/powerbtn.sh > # Initiates a shutdown when the power putton has been > # pressed. > > [ -e /var/lock/suspend-resume.lock ] && exit 0 > > if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop > then > dcop --all-sessions --all-users ksmserver ksmserver logout 0 2 0 && > exit 0 > else > /sbin/shutdown -h now "Power button pressed" > fi > ================================================== > > > In regard to the display returning after resume: what chipset is that? > Which drivers? Are you using the kernel framebuffer? For the native > chipset, or the VESA one? What version of the kernel are you using? > > I have seen those sorts of problems on my own laptop (Radeon FireGL T2 > A.K.A. Radeon 9700) but do not see them now, using the kernel native > radeon framebuffer and a recent 2.6.x kernel. > > Regards, > Andrew McMillan. > > ------------------------------------------------------------------------- > Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington > WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St > DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 > There is no proverb that is not true. > -- Cervantes > ------------------------------------------------------------------------- > -- WBR, Alexander A. Vlasov Debian GNU/Linux user JID: [EMAIL PROTECTED] nic-hdl: ZULU-UANIC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
