Better integration with power management scripts

[Richard Hughes]

On Wed, 2006-04-26 at 18:55 +0200, Holger Macht wrote:
> On Sun 23. Apr - 23:02:25, Richard Hughes wrote:
> > On Wed, 2006-04-19 at 18:47 +0100, Richard Hughes wrote:
> > > * Perhaps apply for freedesktop for the project...
> > 
> > Which I've done, as the general consensus was this shouldn't be hosted
> > by any one $VENDOR.
> > 
> > If you are interested, please subscribe to this list:
> >
> > http://lists.freedesktop.org/mailman/listinfo/pm-utils
> >
> 
> I did, but no mails so far...

Been busy with other stuff, sorry. I need to fire off a load of emails
to ppl about asking people to register to the list.

> > a list for the *sole purpose* of developing these little weedy scripts
> > that do clunky things. Nothing is going to be imported or checked in,
> > until we have a quick design draft that we can all work with.
> 
> This would be great indeed. But why are there already things imported
> before this happended?

Ahh, I think pjones wanted something that worked here and now, although
my personal preference would have been to do this file-by-file.
It does make sense keeping the history I guess, and gives us something
to build on.

>  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.

See above, apologies.

> But now let me start to say what I actually want...
> 
> As a general statement, I don't like these scripts to reside in HAL.
> 
> 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.

Yup, agreed.

> So...
> I (or we) will try to work together with you to find and create this
> common solution. It's a hard decision for me, but I'm willing to go this
> way. But It's only possible if you really keep your promises: Let this
> discussion and implementation take place on an independent list and don't
> import or create anything before everybody agrees with it or, at least, is
> able to life with it. For this reason I've CC'd this new list. Otherwise
> we will again end up in a situation were we fight each other.
> 
> One thing that bothers me is that you try to do things completely
> new. There are already good working and good designed solutions like the
> so called hibernate scripts or the scripts which come along with the
> powersave daemon. We already planned to merge our solution with the other
> existing ones and now I think is the time to do this merge and create this
> new project pm-utils.

I don't like the idea of pm-utils doing anything clever. They should be
*really* simple.

> What we decided yesterday was to provide you with a rough description of
> our design and the different scripts we already use to do these suspend
> things. I really think that they are useable and modular/extendable to use
> parts of them in the future. What we tried over the last month was to make
> them really distribution independent and configurable, removing all
> hardcoded paths (like /etc/pm) etc.
> 
> Therefore I will do this rough overview now and hopefully it is
> helpful. It's important to mention that I definitely do not want to say
> something like: "Please take our solution!". But these have proven about a
> long time to be useable, so I think parts of them are also useable for
> pm-utils. Some things maybe outdated and were just there for hitorical
> reasons and there are also things that maybe done better, but I hope you
> get what I'm trying to say...

Ears open.

> General design
> ==============
> 
>   We separated the suspend into three steps. Preparing (stopping services
>   etc.), doing the suspend (echo [state] > /sys/power/state) and restoring
>   the system to it's original state.
> 
>   We also have some possibilities to communicate with the desktop/user or
>   any other application:
>    
>    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.

I don't think we have to. Telling the user that the suspend failed
because module xyz failed to unload isn't useful. It should just work.

>    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...

How long does modprobing a few modules take? pm-suspend takes an small
about of of time on my system, the largest delay being on the first
sync, which takes less than a second.

>    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.

I don't think this belongs in the HAL or pm-utils layer IMO. It might
belong in powersaved or gnome-power-manager but certainly not in
pm-utils.

>   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.

I really think dbus is too complicated for these incredibly simple
scripts.

> 
> Summary of most important and noteworthy script parts we currently have:
> ========================================================================
> 
> I put a tarball with all the scripts regarding suspend to
> http://powersave.sf.net/powersave-sleep-scripts.tar.bz2 to make it
> possible for everybody to have a quick look without the need to download
> the whole powersaved tarball which these scripts are usually part of.

I'll look tomorrow, as today has been one hell of day! Thanks for the
pkg tho.

> So let's try to work together to find a good solution.

Yes, but give me a couple of days to look through your scripts, and then
we can bash out some details of stuff that needs to change.

Richard.