Date: Thu, 12 Aug 1999 02:52:21 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> To: steveo@iol.ie Cc: iwasaki@jp.freebsd.org, freebsd-current@FreeBSD.ORG, plm@xs4all.nl Subject: Re: recent apm changes Message-ID: <199908111748.CAA10835@tasogare.imasy.or.jp> In-Reply-To: Your message of "Tue, 10 Aug 1999 16:32:37 %2B0100 (IST)" <XFMail.990810163237.steveo@iol.ie> References: <XFMail.990810163237.steveo@iol.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> > Oh, do you have suspend button on your box? Cool.
> > On my poor experience, suspeding by hot-keys easier to
> > success than by zzz(8).
>
> On this point I can report the oppposite experience, on my
> machine (a no name special) the trackpad tends to lock up if touched
> between power on and resume finishing. The best indicator of safety is
> apm -z returning, if I use the button I have to guess.
Ahh, I've seen this kind of behavior on some laptops. I guess this is
related with some sort of time limits on communication with APM BIOS.
APM Spec. v1.2 Appendix D - APM Driver Considerations -----
When an APM connection exists, the APM BIOS transitions into System
Standby and System Suspend states only when directed to do so by a
call from the APM Driver. The calls to change system states are
invoked by the APM Driver only after the APM BIOS indicates that the
state transition should be made, and the APM Driver has checked with
all APM-aware applications to make sure that it is an appropriate time
to change system states. However, there are three cases where the APM
BIOS may make the system state transition itself. The first case is if
the APM Driver does not pick up a posted Standby Request, Suspend
Request or Critical Suspend Notification event within the 2 second
~~~~~~~~~~~~~~~~~~~
(one second plus one second grace period) time limit. The second is
when the APM Driver, after picking up the event, does not respond to a
Standby Request, Suspend Request or Critical Suspend Notification
event with an appropriate Set Power State call within 5 seconds of
~~~~~~~~~~~~~~~~
receiving the event. The last situation is when the APM Driver has
responded to an event with a Request Processing Set Power call and
does not reply again within another 5 seconds.The CPU is power managed
according to CPU Idle and CPU Busy calls made by the APM Driver to the
APM BIOS.
------------------------------------------------------------
Last time, we didn't have `Last Request Processing Notification' to
APM BIOS at all for the second case.
After adding this hack in PAO, we saw greate improvements about system
suspending transition (standby also) on a lot of laptops :)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908111748.CAA10835>