Better integration with power management scripts

[Richard Hughes]

On Tue, 2006-04-18 at 19:48 -0400, David Zeuthen wrote:
> On Tue, 2006-04-18 at 11:41 +0100, Richard Hughes wrote:
> > Further to David's ideas, here are some of my ideas (shamelessly taken
> > from the ubuntu pmi and fedora pmscripts):
> > 
> > Create a /usr/share/hal/scripts/pm/hooks directory that distros and
> > vendors can dump files into that do things on resume and suspend, for
> > example:
> > 
> > * unloading certain modules and re-modprobing them if required
> 
> My position is that if a module needs to be unloaded and loaded again
> there is a bug in the module that needs to be fixed. We should never do
> this but providing the infrastructure for OS vendors, hardware/driver
> vendors and users is fine. After all, we all know it takes time to fix
> this.

After a *long* chat on IRC, some more concrete ideas:

* Get methods for suspending and resuming the display integrated with
HAL as we can use fdi files to pick and choose how to resume each type
of adapter. Something like video.tool_method (string) = "radeontool" and
then all we have to do is call VideoResume() on the adapter, which
launches the hal-system-video-resume script which does the resume (like
the lcd brightness one).

* Make hal depend on project pmt[1] unconditionally.

* Make project pmt integrate with hal-system-power-* scripts, and get
rid of the pm-utils, pmi, and PowerSave stuff in the existing scripts.

Please see the attatchment of the IRC log, and you can see some of the
rational (and arguments).

Project pmt:

What is it?

* Provides simple shell command line tools to suspend and hibernate
computer that can be used to run vendor or distro supplied scripts on
suspend and resume. Does not depend on HAL.

What isn't it?

* There are no permission checks, no use of C, and certainly no DBUS!

Why do we need it?

* As all the main distros are re-implimenting the same thing, over and
over, to do something that's really quite trivial. Having the common
locations for stuff means that software and hardware vendors can just
install one file to do the clever stuff that pmi & acpi-support (Ubuntu)
and pm-utils (Redhat) are doing. HAL will use these scripts to perform
the Suspend() and Hibernate() methods and then we can remove all the
legacy cruft where we check for per-distro tools.

* Distros can easily add/remove functionality by installing/removing one
file into the hooks directory, for example:
- enabling and disabling standby LED's on laptop hardware 
- enabling suspend GUI's like suspend2 
- re-enabling video (perhaps using HAL, see above) 
- starting and stopping services that can't cope with suspending 
- re-syncing the time with ntp 
- removing and modprobing modules when needed 
- setting grub to be the default target for a hibernate-resume 
- other wacky things that need doing on specific systems

* Perhaps apply for freedesktop for project pmt, or use the existing
pm-utils codebase available at:
CVS :pserver:anonymous at cvs.fedora.redhat.com:/cvs/devel, module is
"pm-utils"

* The future: When every module and program can deal with a
suspend-resume cycle, and all the LED's work, and stuff doesn't break,
then this module is obsolete. Until utopia arrives, I think this is
required.

[1] pmt is a silly name. We need to decide on a better one, perhaps pmi
or pm-utils even.

Discuss: :-)

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: #hal.log
Type: x-directory/normal
Size: 29981 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20060419/c933e636/hal-0001.bin