Better integration with power management scripts

[David Zeuthen]

On Wed, 2006-04-26 at 18:55 +0200, Holger Macht wrote:
> This would be great indeed. But why are there already things imported
> before this happended? And why are there posts about this topic on the
> HAL list excluding the pm-utils at lists.freedesktop.org list? And not
> one single mail on that independent list so far. So please continue
> discussion on the new list and ping the authors of the different
> existing projects to give them at least chance to get involved.

Well, there's 250+ people subscribed to the hal list. I don't really
think anyone wants Yet Another Mailing List to subscribe to. Plus, I
want pm-utils to be so simple that it's done to everyones satisfaction
in a few weeks and we never need to change it from there. So I'm not
really sure we need another list, but Richard created one anyway... I
say we keep it on the hal list for practical reasons.


> But...
> this seems to be the way most people like to go, although not all people
> involved in power management read the HAL list. SUSE, respectively me,
> likes to definitely avoid a situation in the future where HAL has one way
> of doing things and the powersave daemon/SUSE has another one. The common
> goal should be to have one solution which fits everybody's needs and
> that's definitely something we agree in.

Yes, with the underlying theme that things should be kept very simple. I
don't want pm-utils to export any D-BUS services itself but providing
infrastructure for this is fine with me. The only use of D-BUS in
pm-utils proper should be to ask HAL to resume the video cards (and
gracefully work if HAL is not available, e.g. no timeouts). That's it.

>    1. Send a message over dbus about a notice, a failure or an
>       error. There's definitely the possibility that _something_ goes
>       wrong during preparation of the suspend. For example "Failed
>       unloading module xyz because device is still in use". That's just
>       one example, but IMO there might definitely arise something like
>       that. Maybe we add a dbus interface like
>       org.freedesktop.PowerManagement.SuspendMessages or the like which
>       applications can listen to show these messages to the user.

So, I think my point of view is basically this: If a user knows what
"Unloading module xyz because device is still in use" means he also
knows to look at the syslog. I basically think it's about us realizing
what users we are designing for. I realize this point of view may be
GNOME contric and e.g. KDE centric distributions might want to put up
such messages for whatever reason. They should have that freedom but I
shouldn't make pm-utils a lot more complicated.

So I think we need to do this

 1. pm-suspend and friends needs to return errors in a standardized
    format, e.g. predefined set of error codes. Also, they should
    put the reason in a file in /tmp. Then our HAL handler (which is
    hal-system-power-suspend) can interpret these return codes and throw
    the right exception. For example we might define the exception
    org.freedesktop.Hal.Device.SystemPowerManagement.LKMFailedToUnload
    with where the textual part of the exception is the name of that
    Loadable Kernel Module. Implementation-wise the HAL handler simply
    checks the return code (it may be 5 for LKMFailedToUnload) from
    pm-suspend and reads /tmp/pm-utils-failure-reason for the name of
    the LKM

 2. No matter what pm-utils should log useful failure to syslog this
    both users, admins and developers are going to look in that
    location. So in the event an LKM fails to unload we simply also
    put an error there.

How about that?

>    2. Send messages over dbus to report the current progress of the
>       scripts. In our case, we show a progress bar in kpowersave shortly
>       before suspending which says something like "unloading module xyz"
>       or "stopping service xyz". For this purpose we added some progress()
>       fuction calls to our scripts in different places. That's just a nice
>       to have feature but in general it might be valuable. Maybe we can
>       seperate the suspend cycle in different stages like NetworkManager
>       does. This would also be needed for any graphical bootsplash to show
>       this. Something like org.freedesktop.PowerManagement.SuspendProgress
>       comes to my mind...

You know, obviously the right fix is to make suspend very fast (and
Windows and Apple shows us this can be done) and I still think you don't
know who you are designing for if you want to bother the users with
technical jargon. Also, I really really don't want pm-utils to send out
D-BUS signals by itself. 

But it would be fine with me if it did something like

 notifiers="/etc/pm/notifiers/*"
 for n in $notifiers; do
   [ -x $n ] && $n <what we are doing now> <more detail>
 done

Then for example all the KDE or SUSE UI gizmo for showing progress can
install a handler that sends out a message. It might even want to use
DCOP, who knows :-)

Would this work for you?

>    3. For user interaction, we need a possibility to ask questions. Just
>       some simple examples like "do you really like to suspend although
>       there are other users logged in" or "really suspend? There is a CD
>       buring job running". That's not yet in our scripts but is something
>       we should have in mind for the future.
> 
>   It would be easy to have a function notify_user() or progress() which
>   does a dbus-send or looks into a directory if there is a script to
>   execute for this purpose. All this is something we have already and it
>   would be hard for us to have a regression in this area because it's
>   something our users really appreciate.

As Matthew points out this should be handled by the power management
daemon, e.g. powersaved or gnome-power-manager or whatever. 

Do you agree?

Cheers,
David