G-P-M on the wrong track?!

[John (J5) Palmieri]

On Mon, 2005-10-17 at 15:53 +0200, Danny Kukawka wrote:
> On Monday 17 October 2005 14:42, you wrote:
> > > This is what we do with powersave [1] on SUSE and ALT Linux. There is a
> > > (desktop and arch (ix86, ix86_64, ia64 and now also ppc) independent)
> > > daemon which only do powermanagement and which also do powermanagement if
> > > there is no desktop user logged in.
> >
> > What use case has this got? How many times on battery do you leave your
> > laptop at the login screen? There was talk of integrating g-p-m with gpm
> > so that it runs at the login prompt (with the preferences of root), but
> > I'm not sure how far this idea actually got.
> 
> This is a needed feature. There are not only laptops on battery. This was only 
> one example. Other expample: You run you laptop on AC or your desktop machine 
> and want to suspend or change cpufreq or set a special powerscheme as 
> user/root without login to desktop. There are many possible use cases. We 
> know this requirement from develop powersave and SUSE users since the start 
> of the project. There are also several user which want to use the daemon 
> without login from a script and also this work well with powersave.

This makes sense.  After rethinking my earlier assessment there are a
couple of reasons to have a separate daemon.  First is security, with a
separate daemon we can define who can talk to it a lot easier though I
am not convinced what HAL does right now is of any risk.  Second is your
point about non-loggedin behavior.  There is no way for the HAL addons
to set policy so even if we kept the functionality in HAL a client
daemon would still have to be run as root.

It shouldn't be that hard to extract the functional bits from g-p-m and
put them into a daemon.  I don't know if powersave is the best place or
not.  It looks good but I am concerned about powersave trying to do too
much but then again I only took a five minute glance at the code.

After reassessing, HAL should definitely remain the canonical source for
all information on management devices with the daemon being used for
system wide default policy and interface for overriding that policy by
logged in users (or scripts, or whatever).  In other words as stated
elsewhere in this thread we need a constant D-Bus interface and a daemon
that implements it.  It shouldn't be hard in the short term to make g-p-
m's functional bit into a daemon and then in the long term perhaps merge
powersave and the daemon part of g-p-m.  I think the design goals are
all the same and this is just implementation details.  

How far along is powersave in using HAL as the source of device info?
Merging the bits that HAL doesn't do would be good.  

This is all stuff that is just better if we all collaborate on one
solution.  The client are different but on the backend it seems
worthwhile.  Powersave should really be moved to fd.o if we do go down
that road but that is a different issue.

Richard is this all good with you?

-- 
John (J5) Palmieri <johnp at redhat.com>