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 acpid packages)
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 do anything?
"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)?
s/aren't/are/
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' suspend-to-RAM?
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 pressed.
*** 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: zprikryl
updated
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. Zdenek
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.