Re: Announcement: Common Power-Management Framework
Kevin Locke <kwl7@cornell.edu> wrote:
> Interesting. I wasn't aware to what extent HAL is able to notify
> programs about power-related events. In fact, we had briefly discussed
> receiving events from HAL in addition to the power-daemons. Perhaps
> with some work, we would be able to rely completely on HAL.
At the moment, HAL will listen for ACPI events and has partial support
for PMU notifications. APM is a bit more awkward, since the standard
doesn't really allow for a great deal of policy - the system is told
that a suspend is going to happen, has an opportunity to run some code
and then the system suspends. This can possibly be hacked around in the
kernel to some extent, but, well.
However, the basic idea behind using HAL is to get PM event notification
in a platform independent way. Whether it's an ACPI or a PMU-based
system is fairly uninteresting - userspace just wants to know that the
user has pressed the power button, pulled the poewr, closed the lid or
whatever. HAL provides that, so lets the policy daemon be entirely
ignorant of the underlying hardware.
> The common power-management framework is really intended to be a policy
> layer, so it may still have some value for running scripts based on
> power events (it could fill the roll of the "small daemon" you talk
> about in your second mail to this thread). However, I realize that the
> GNOME Power Manager[1], and likely a KDE equivalent, already handles
> several of the tasks normally associated with power-management, so
> perhaps there is no need for another program to be handling events.
Gnome power manager is an implementation of a policy daemon, yes. It's
well-suited to certain types of desktop environment, but it's not
ideally suited to server environments. On a desktop, stuff like
screen-blanking and response to lid closing is a per-user preference,
whereas on a server you probably don't want users to be able to fiddle
with that.
> What are your (or anyone else's) thoughts about the value of a daemon to
> invoke scripts based on the power-related HAL events? Is this
> unnecessary given the function of the GNOME Power Manager and
> equivalents, or would it have enough value to be worth implementing?
HAL will call scripts to perform certain actions, such as triggering
suspends and (where possible) will do things like altering screen
brightness on request. The policy daemon is responsible for asking for
these things to happen, and is also necessary for notifying other bits
of userspace.
> Would it be better to spend our time adding features to the Gnome Power
> Manager and equivalents instead of creating a separate program? I'm
> sure we will be discussing this extensively on the powermgmt-devel list
> in the near future, but I would like to hear what the -devel community
> thinks of this idea (it's too easy to justify ones own work in ones own
> mind).
I think a small, light daemon that runs configurable scripts on various
HAL events would be an entirely sensible thing to implement. Ideally, it
should check whether some user manager has started and (depending on
configuration) let that take care of things instead. That way, there's a
system-wide config up until the point where someone logs in.
So, I think the best plan of action would be:
1) Implement a small PM daemon on top of HAL (basically a replacement
for apmd, acpid and pmud)
a) Should call HAL for system state transitions
b) Should call scripts installed by other packages
c) Should be configurable in terms of default response to actions
d) Should (optionally) get out of the way if a user runs a power
management daemon
2) Define a mechanism for packages to drop scripts into this framework
3) Ensure that packages like gnome-power-manager and whatever KDE come
up with are able to call the same scripts when necessary
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
Reply to: