Better integration with power management scripts

[David Zeuthen]

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.

> * stopping and starting certain services

Ditto.

> * re-initialise the video of video cards as reqd.

Yea, we need this too since X.org / fbdev isn't going to be fixed
anytime soon

> * making the ibm led blink (echo "7 blink" > /proc/acpi/ibm/led)

Yea, this is cute.

> And we only need one common pm helper script, for example returning what
> kind of video adaptor (Intel, ATI, NVidia) you have or general useful
> code we want to use in the pm hooks.
> 
> I think this is required as all the main distros have different ways of
> doing this, for example pmi for ubuntu and pm-* for fedora, when all
> this stuff is *really* simple and should be centralised in HAL so
> vendors (hardware vendors like IBM or software vendors like Oracle)
> could provide one file that works on any distro.
> 
> Any stuff like enabling bootsplash or doing other clever-stuff, one file
> can just be dropped in /usr/share/hal/scripts/pm as required.
> 
> Comments? Please bear in mind the general idea is to make this easy for
> a user to suspend and hibernate, not some political statement using HAL,
> so please keep critique technical.

Possible objections and my take

 - "HAL is becoming the kitchen sink"
   No, we're just trying to get all vendors to use the same software
   and format so everyone benefits.

 - "We don't want HAL on servers and suspend/hibernate is important on
   servers too"
   If HAL is not suitable for servers, it's certainly fixable and
   something we want to fix anyway. The benefits, as listed below,
   are simply too great to not use HAL for this. As a data point, at
   least RHEL4 and FC3-Rawhide runs HAL by default. I think the same
   is true for other distributions too.

In short, the whole idea of having a single well-defined format via
device information files is by far preferable to all the various file
formats the various distributions are using right now. 

It means that 

 1. if I'm Dell, Lenovo, HP etc. I can simple write one simple file and
    it will work on Fedora, Debian, Ubuntu, SUSE, Mandriva and so forth.
    In short, we make life much simpler for laptop vendors and everyone
    wins. Also, upstream projects can hook into this framework if it's
    universal across operating systems (not that they should, but they
    could)

    In particular, my guess is that said laptop vendors wants something
    like this.

 2. By continuing to use HAL .fdi files as the single format for device
    specific information it becomes much easier to write a proper
    hal-device-manager style application that allows users to 

    2a. edit this information and install it locally (probably via
        PolicyKit to handle the auth) [1]

    2b. share it by using a bug-buddy mechanism that automatically
        files a bug at bugs.fd.o

 3. The HAL .fdi file format is pretty easy to understand for stuff
    like this

I, for one, really think we should do this. I can't speak for any
distributors (not even Fedora) or other stake holders (such as Nigel who
is one of the experts on this area) or contributors to HAL and the
underlying systems (udev, kernel, mkinitrd etc.). Please let us know
what you think.

Thanks,
David

[1] : It would be great if someone could propose this as a SummerOfCode
project for either GNOME, KDE or both (using a huge pile of shared
code). I, for one, really wants to retire hal-device-manager. I think
the time is about now. If anyone wants to take this on, please post your
ideas to this list and I'd be happy to provide my input on how it should
work (I got lots of ideas). 

I'll even throw in help on bug-fixing but I just cannot commit to taking
on yet another project these days (Besides OLPC, I've already got HAL,
PolicyKit, gnome-mount and I'm looking after the gnome-vfs2 HAL backend)