[Pm-utils] Re: Better integration with power management scripts

[David Zeuthen]

Hi,

Looks like we are finding a middle ground :-)

On Thu, 2006-04-27 at 21:23 +0200, Holger Macht wrote:
> You know what controversy currently exists in regard to power management
> and HAL. 

Yeah and I don't really get it. The mechanism for how HAL implements
Suspend(), Hibernate(), SetLowPower() is pretty uninteresting and that
is all what pm-utils is about.

> And I liked the idea of starting a new project, leaving
> everything behind what has been and trying to find a proper solution for
> the future. I would also appreciate to see other power management guys
> invited to get involved. At the power management summit this year, we
> decided to create a new list to go that way for everything related to
> power management in userspace, not only suspend. And I liked this idea. Of
> course, pm-utils@ is only for suspend, but the general approach applies
> here, too.

Sure, I'd like that too.

> But without any information system, the user maybe does not even know that
> he should look into syslog. You click suspend, and... nothing happens. 

Well, on failure Suspend() on HAL throws an exception and I believe
g-p-m puts up a notification on your desktop. 

> We
> had that, and the feedback we got inspired us to change it. So I think you
> understand that I wouldn't like to see a regression in this area. And I
> agree with you that "unloading module... failed" might be to technical for
> desktop distributions.

Yea, it's the equivalent of saying "Suspend failed because the computer
couldn't turn purple and run the Hypervizor at Warp 3". But it's useful
for people like you and me and the other 0.5% of the earths population
that knows what it means. And we both know to look in syslog.

> >     pm-suspend and reads /tmp/pm-utils-failure-reason for the name of
> >     the LKM
> 
> Well, sounds a little bit too complicated for me instead of having an
> interface org.freedesktop.Hal.SystemPowerManagement.SuspendFailure the
> pm-utils script emmits signals over with two arguments, a return code and
> an optionl variable string, e.g. int32:5 string:<the module name>. In case
> hal does not exists, pm-utils scripts still can write this information to
> /tmp or syslog. It's just a function which determines if Hal is available
> or not when the scripts are started.

I'd like pm-utils to be lean and I don't want it to depend on whether
D-BUS is available. There's probably better ways of doing error
reporting though.

hughsie, pjones, mjg59: How do we sanely report errors in pm-suspend and
friends?

> Yes, sound good, not only for a rmmod failure, but also for other things
> that _might_ go wrong. Hopefully there will never be such situations ;-)

Sure, we just need to define the return codes for pm-suspend and friends
and where to put the textual output too.

> > Do you agree?
> 
> Basically, yes.
> 
> But I still fear that applications won't have enough knowledge to handle
> this. But with the "notifiers directory solution", should be possible.

Cool.

hughsie, pjones, mjg59: Are you guys opposed to having a notifier
interface?

Cheers,
David