The current kernel ( 2.4.2-ac26 or 2.4.3-pre8 ) has
arch/i386/kernel/apm.c version 1.14 while version 1.15
is available as a patch to 2.3.99-pre7-1 ( read :
it was available for ages ) at http://linuxcare.com.au/apm/
The newer version has among other things support for
the APM_IOC_REJECT ioctl which is useful for example
when implementing "run /sbin/shutdown -h when the power
button is pressed".
While isn't this merged into the official kernel ?
Is apm.c v1.15 the latest ?
The last modification of the http://linuxcare.com.au/apm/ page
was in may 2000 and in 2.4.2-ac25 the web address for the APM driver
was changed to http://www.canb.auug.org.au/~sfr/ , but that page
doesn't have much/any content about the APM driver.
On a related note :
Both Abit BH6 and MSI K7T Pro2A send a SYSTEM_SUSPEND APM event
( APM_SYS_SUSPEND ) when I press the power button. When the OS
acknowledges the event, the system doesn't go to suspend , as
the OS expects , but to power-off , killing all running processes
and causing an unclean umount , among other things.
Is this the APM standard behavior or do I have two weird motherboards ?
P.S.: Looking for an archive of the [email protected]
mail list.
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
John Fremlin wrote:
>
> David Balazic <[email protected]> writes:
>
> > John Fremlin wrote:
> > >
> > > David Balazic <[email protected]> writes:
>
> [...]
>
> > > The maintainer hasn't the time to do it. He promised me he would in
> > > February, when I telephone, but hasn't bothered to do anything
> > > AFAICS. I hacked together the following patch for it a while ago,
> > > which updated APM_IOC_REJECT for slightly more recent kernels (be
> > > warned, I think I made some mistakes)
> >
> > It uses the same version number ( 1.15 ) as the "official" apm.c (
> > at linuxcare.com.au/apm ). I don't think that is a good idea. Maybe
> > 1.14b ?
>
> Well it's not going to go anywhere unless you want to look after it so
> there's not much point in worrying about that :-)
And the 2.4.2-ac26 apm.c has version 1.14 changes listed that are different
from the 1.14. changes listed in the patch from linuxcare.com.au/apm,
so it is not as big problem as I thought.
> [...]
>
> > > I made a (IMHO) better version called pmpolicy, based on different
> > > principles. More information is available at
> > >
> > > http://john.snoop.dk/programs/linux/offbutton/
>
> > To implement off-button you only need the APM_IOC_REJECT ioctl and
>
> The problem on my computer with my (re)implementation of
> APM_IOC_REJECT is that the screen goes into powersaving when the user
> suspend is received, then turns it back on when APM_IOC_REJECT is sent
> by apmd.
What is wrong with that ?
Suspend is requested -> suspend is executed
Suspend is canceled (rejected) -> suspend is canceled
Seems perfectly OK to me.
> Stephen said this was something wrong with my implementation
> (???).
User error ? :-)
> Anyway it is fixed in my pmpolicy patch, and I don't need no
> daemon so the code is a lot cleaner and simpler (no binary magic
> number interfaces).
But there should be no policy in the kernel ! ;-)
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
David Balazic <[email protected]> writes:
> John Fremlin wrote:
[...]
> > > To implement off-button you only need the APM_IOC_REJECT ioctl and
> >
> > The problem on my computer with my (re)implementation of
> > APM_IOC_REJECT is that the screen goes into powersaving when the user
> > suspend is received, then turns it back on when APM_IOC_REJECT is sent
> > by apmd.
>
> What is wrong with that ?
> Suspend is requested -> suspend is executed
> Suspend is canceled (rejected) -> suspend is canceled
>
> Seems perfectly OK to me.
The sequence is in fact: suspend requested by BIOS -> suspend accepted
by kernel -> SUSPEND -> suspend rejected by apmd which is passed on by
kernel to BIOS -> REJECT=RESUME (if I understand correctly, this is
what seems to happen).
Sequence should be as in pmpolicy patch: suspend requested by BIOS ->
/sbin/powermanger decides to reject -> REJECT
[...]
> > Anyway it is fixed in my pmpolicy patch, and I don't need no
> > daemon so the code is a lot cleaner and simpler (no binary magic
> > number interfaces).
>
> But there should be no policy in the kernel ! ;-)
Read the patch. Read the webpage:
http://john.snoop.dk/programs/linux/offbutton
There is no policy in kernel.
--
http://www.penguinpowered.com/~vii
John Fremlin wrote:
>
> David Balazic <[email protected]> writes:
>
> > John Fremlin wrote:
>
> [...]
>
> > > > To implement off-button you only need the APM_IOC_REJECT ioctl and
> > >
> > > The problem on my computer with my (re)implementation of
> > > APM_IOC_REJECT is that the screen goes into powersaving when the user
> > > suspend is received, then turns it back on when APM_IOC_REJECT is sent
> > > by apmd.
> >
> > What is wrong with that ?
>
> > Suspend is requested -> suspend is executed
>
> > Suspend is canceled (rejected) -> suspend is canceled
> >
> > Seems perfectly OK to me.
>
> The sequence is in fact: suspend requested by BIOS -> suspend accepted
> by kernel -> SUSPEND -> suspend rejected by apmd which is passed on by
> kernel to BIOS -> REJECT=RESUME (if I understand correctly, this is
> what seems to happen).
>
> Sequence should be as in pmpolicy patch: suspend requested by BIOS ->
> /sbin/powermanger decides to reject -> REJECT
AFAICT , the kernel does not accept(*) any APM_EVENT until all userspace
"listeners" say it is OK. So until apmd doesn't reply, the kernel does
not accept the SUSPEND. If apmd says OK, kernel says OK to BIOS and SUSPEND
is activated, but if apmd says NO-NO, then the kernel rejects the SUSPEND
request and "nothing happens"
This is of course with a proper implementation of REJECT functionality
in the kernel apm driver. I don't know if it behaves like this in the
current IOC_AOM_REJECT version, but it should :-)
* - by accept I mean : it receives a notification from BIOS and replies
OK to the BIOS. the BIOS doesn't change the powerstate until the kernel
responds with OK , IIRC
>
> [...]
>
> > > Anyway it is fixed in my pmpolicy patch, and I don't need no
> > > daemon so the code is a lot cleaner and simpler (no binary magic
> > > number interfaces).
> >
> > But there should be no policy in the kernel ! ;-)
>
> Read the patch. Read the webpage:
>
> http://john.snoop.dk/programs/linux/offbutton
>
> There is no policy in kernel.
>
> --
>
> http://www.penguinpowered.com/~vii
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -