My apologies for the saga appearing below, but I'm starting to get
confused about where Debian is going vis a vis power management for laptops,
and hoped to beg some advice.

I currently have 'laptop-mode-tools', 'acpi-support', and
'hibernate' installed, which have served me well in the past. I selected
them because:
- 'laptop-mode-tools' appears to be the best maintained tool for
flipping in and out of power saving modes when the mains are
unplugged;
- 'hibernate' has facilities for stopping and restarting services
and unloading/reloading kernel modules that don't behave well.
'acpi-support' recently grew something similar to this, but from
reading the scripts, it looked like 'acpi-support' and 'hibernate'
could have a fight over who does what, and it wasn't clear who
would or should win. So I stuck with 'hibernate';
- I don't, as a rule, use GNOME or KDE, and prefer all the little
daemons running around to be universal and work no matter which
window manager (*cough*WindowMaker*cough*) I happen to be using,
including none at all.

Anyhoo, I recently grabbed 2.6.24 and compiled my own copy. I
always grovel through almost the entire config space, and found this
somewhat imperious declaration for ACPI_PROC_EVENT:

----
A user-space daemon, acpi, typically read /proc/acpi/event
and handled all ACPI sub-system generated events.

These events are now delivered to user-space via
either the input layer, or as netlink events.

This build option enables the old code for legacy
user-space implementation. After some time, this will
be moved under CONFIG_ACPI_PROCFS, and then deleted.

Say Y here to retain the old behaviour. Say N if your
user-space is newer than kernel 2.6.23 (September 2007).
----

I keep my userspace pretty much pegged to 'unstable', which seems to
me to be newer than September 2007. Yet when I turned on
CONFIG_ACPI_PROCFS, things started breaking.

'acpid' won't run at all, since /proc/acpi/event no longer exists.
Okay, fair enough, except that this causes 'laptop-mode-tools' to do
essentially nothing, since ACPI events are no longer generated to drive it,
and it doesn't appear to have grown support for the input layer or netlink
events.

After some Googling around, it seems there's a movement afoot to
have all power-related stuff go through dbus. The only thing I've located
so far that handles this is 'gnome-power-manager', which seems to lack the
flexibility of 'acpi-support' and 'laptop-mode-tools', and it seems
(unconfirmed) to demand an X server be running.

I can turn CONFIG_ACPI_PROCFS back on in the meantime, I suppose,
but I was wondering where things were headed with this. Are there any
"generic" daemons out there using the new event facilities that serve as a
reasonable replacement for 'laptop-mode-tools' and/or 'acpi-support', and
which work without X running?

Thanks in advance.

Schwab


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

> Are there any "generic" daemons out there using the new event facilities
> that serve as a reasonable replacement for 'laptop-mode-tools' and/or
> 'acpi-support', and which work without X running?

After grovelling around in a bunch of config files, I've partially
answered my question.

'gnome-power-manager' is built on top of HAL, and performs all its
actions through the org.freedesktop.Hal.Device.SystemPowerManagement
interface. So, digging around through the HAL files, I found the scripts --
conveniently enough in /usr/lib/hal/scripts -- that are actually invoked to
perform the actions. These scripts are themselves clients of 'pm-utils'
(indeed 'hal' lists 'pm-utils' as a dependency). And 'pm-utils' has (just
barely) the functionality needed to unload and reload flaky kernel modules
on suspend and hibernate. It doesn't yet have the ability to specify a list
of services to stop/restart, but the infrastructure's there.

Now all I need is a non-GUI daemon to drive the whole thing.

Schwab


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org