I believe that acpid should come with some reasonable default configuration
file. In particular, it would probably be a good idea to call
/etc/sysconfig/apm-scripts/apmscript for resume/suspend/power change - this way
APM -> ACPI migration would be *much* easier. (Of course, that would mean that
/etc/sysconfig/apm-scripts/apmscript would have to be included in both apmd and
More or less deferring for now. ACPI will not be in the release.
Now acpid is the defaut again and again I lost:
- any ability to figure out what the battery status is
- any ability to suspend/resume
on my Dell Lattitude C640
acpid does neither of those things for you.
battery status requires parsing the acpi battery format file (i.e., a bug in
whatever monitor applet), or having acpi have a backwards compatible /proc/apm
(a kernel solution.)
Suspend is more-or-less entirely a kernel implementation issue.
Are you saying that BIOS suspend is not going to be available with ACPI and I
can only hope for swsuspend?
Try 'echo "S4" > /proc/acpi/sleep' (I think that's the right file) - does that
"cat /proc/acpi/sleep" shows: S0 S1 S3 S4 S4Bios S5
"echo S4 > /proc/acpi/sleep" and "echo S4Bios > /proc/acpi/sleep" seem to be
silently ignored (same with S0, S1, S3 and S5).
echo S4 does nothing here too (Compaq Evo N1015v).
When the ac and battery module is loaded, you should get the ac and battery state.
why aren't these modules not modprobed when loading acpid (only button)?
Ah, it should be just "4", not "S4"! On my laptop, echo 4 > /proc/acpi/sleep
gets me a BIOS message telling me I have no hibernation disk partition (which is
true). Now the question is - is one of those S levels supposed to give me BIOS'
No suspend-to-RAM at all on 2.4. Apparently works on some systems in 2.6.
*** Bug 101189 has been marked as a duplicate of this bug. ***
This should be fixed before Cambridge.
sample.conf in FC1 is ok (reaction on button/power)
please CLOSE with resolution CURRENTRELEASE
sample.conf is completely insufficient! ACPI should do something
reasonable for suspend/resume and power changes (switching between AC
and battery, and low battery)
well I am do it exactly this, next weekend maybe I ll post some here
and It is very easy.
I have already the project name: "ACPI logger"
*** Bug 124585 has been marked as a duplicate of this bug. ***
*** Bug 120991 has been marked as a duplicate of this bug. ***
Created attachment 105637 [details]
enable sleep mode
This patch enters the machine into the sleep mode (S3) when the sleep button is
*** Bug 137517 has been marked as a duplicate of this bug. ***
Created attachment 107750 [details]
enable sleep mode
*** This bug has been marked as a duplicate of 111958 ***
Bug 111958 ended up being marked as a dup of bug 169476, which simply asks for
acpid not to interfere with gnome-power-manager when both are running.
But when no gnome-power-manager is running (the user is using KDE or nobody is
logged in), we still need a reasonable default config for acpid - including
things like handling the sleep mode and tweaking the "laptop" mode parameters on
AC/battery transitions (the same way apmscript used to do it for APM).
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Package Change Request
Package Name: acpid
Updated Fedora Owners: email@example.com
Problem is, that each vendor uses different acpi codes for keys and events (lid,
sleep button, etc). So there is no way, how to simply create common scripts for
those things. One can create lot of event handlers in /etc/acpi/events/*, on
this days contains only two basic scripts. But this event handlers depend on a
NB or a PC which you use. Today, many users use combination of HAL, pm-utils and
quirk instead acpid for handling this stuff. It is simpler to set and use. For
more info check http://people.freedesktop.org/~hughsient/quirk/index.html.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
I use RHEL, not Fedora these days and have no idea if this is still relevant.
Should this bug remain open?
No, I think this bug should not remain open. There is no way how to create
universal scripts. Reason is that each vendor has his own ACPI codes for events.
So one have to create scripts by himself.