acpi-apm V0.1

What is this?

acpi-apm is a Linux kernel module that simulates the output from /proc/apm on systems that have ACPI, not APM, for power management. Why is this useful? A great deal of software uses /proc/apm to determine the power status, include the Gnome panel applets. There are equivalents for ACPI, but they never seem to work very well. With this module, it appears to applications like Gnome that APM is in charge.

Please note that it does not simulate the control features of APM, only the monitoring. You won't be able to use this module to give you a suspend-to-RAM feature if your kernel doesn't support it through ACPI.

acpi-apm works by intercepting reads made on /proc/apm, determining the power status from the ACPI BIOS, then simulating the APM values based on the ACPI values. You need to have ACPI support compiled into your kernel and working before using the module.

What kernels does it work with?

This module has only been tested on a 2.4.18 kernel, with ACPI patch 20020918-2.4.18. It may work with other kernels and other ACPI patches: your mileage may vary. I would be happy to hear about problems if it doesn't work: please send a full output from the compiler or a kernel stack dump or whatever is appropriate.

Compiling and installing

Unpack the archive and run make. If it doesn't compile, e-mail me. The compilation should generate the file acpi-apm.o. Load this into the kernel by doing insmod acpi-apm.o. That's it. If you do a cat /proc/apm you should see some numbers in decimal and hex. If you get a segmentation fault, e-mail me. How you get the module loaded at boot time is up to you: rc script or whatever.

Bugs and limitations

If you insert the module, then remove it, and continue to try to use /proc/apm, weird things happen. I can't figure out whether the fault is in my code or the ACPI support. If anyone can, please let me know.
The module attempts to work out how long the battery will continue to run the machine. If the battery is on charge, the result will generally be nonsense because the ACPI BIOS reports the current drawn from the battery, not by the hardware. Of course, off charge these two figures are the same. On charge, the current drawn by the battery is a nonsense figure. The only way to fix this problem would be for the module to record the discharge figures whenever the battery is off charge, and try to interpolate when on charge. This just seems like too much of a chore.
Only one battery is monitored, even though some systems support more than one battery. I think that it won't fall over completely with more than one battery, and it may even produce valid results if the batteries charge and discharge together. But it won't be perfect. Again, it was just too much of a chore to write the code to add up the charges, average the discharge rates, etc.
To reduce the number of ACPI calls, the software does not interrogate ACPI for the mains power status. Instead, it assumes that there is mains power if there is no battery reported, or a battery is reported as charging. It seems to me that this is a not quite an infallible algorithm. I thinks it's safe to assume that if there is neither mains power nor a battery, then you won't have a running machine. But isn't necessarily true that if there is mains power then the battery must be charging. Where it will fall down is if your BIOS shows the battery in the `ok' state rather than the `charging' state when it is fully charged on mains power. Then it will look like the mains has been switched off. However, it works correctly on my laptop, which is why I wrote it.
One of the values output from /proc/apm is called `battery_flag'. It's never been clear to me what this is for. This module sets -1 to this field which does not appear to be a problem. I guess that means that the client software doesn't read it.

Author and legal

This kernel module was written by Kevin Boone and is (c)2002, distributed according to the GPL. Some parts are (c)2002 Intel Corporation, also distributed according to the GPL. You may do whatever you like with this code, provided that this authorship continues to be acknowledged and source code remains available. Needless to say, there is no warranty of any kind, and you use this at your own risk. Please report bugs, etc., to kb@kevinboone.com.