screensaver and power manager dbus interfaces

[Holger Macht]

On Fri 02. Jun - 18:11:10, Richard Hughes wrote:
> On Fri, 2006-06-02 at 19:00 +0200, Holger Macht wrote:
> > On Fri 02. Jun - 17:48:14, Richard Hughes wrote:
> > > On Fri, 2006-06-02 at 18:40 +0200, Holger Macht wrote:
> > > > Ok, then it is more than sane to add all power management related methods
> > > > here. Like all display brightness related methods which are already in
> > > > Hal.
> > > 
> > > This is more sane than you think. g-p-m dims the screen when the user is
> > > idle to save battery power (lots!), so externally stabbing at hal to
> > > change the brightness would be the wrong thing to do here, instead
> > > informing g-p-m of the new ideal un-dimmed brightness would be what the
> > > application would want to do.
> > 
> > Well gnome-power-manager does this, noone else. You have to give any other
> > application the possibility to implement that. Why not through
> > org.freedesktop.PowerManager?
> 
> You mean to change the brightness of the machine? In which case yes,
> this should be added to the spec so that another application can set the
> brightness of the display.

Another method org.freedesktop.PowerManager is just a proxy for. The
dbus-aware desktops have the possibility to query hal directly.

> 
> > > 
> > > >  Well if we mirror DPMS settings because on some systems we don't have
> > > > an X server, then we have to mirror _all_ power management related tasks,
> > > > because there are also systems which have no running hal. Like UPSs,
> > > > battery information, ac states.  We would have to duplicate almost
> > > > anything on org.freedesktop.PowerManager.
> > > 
> > > Only the bits that make sense, i.e. things that dabble in session stuff.
> > 
> > So what of the examples I wrote aren't important for the session?
> 
> Umm, foo.bar.PowerManager shouldn't abstract the data from HAL, but
> allow session interaction with a power manager. I'm not sure why you
> would want to abstract all that extra info. Finding out if a computer is
> on AC power would be a valid abstraction (as it's not trivial to do in
> HAL due to UPS's etc), but not the capacity of a specific battery.

Not of a specific battery, but the added up battery state, e.g. All
batteries together have 7% lifetime left. That would indeed be needed to
make fine grained policy decisions.

The point is that I see no need for duplicating just _some_ of the methods
(e.g. DPMS) for arguments which are valid for most other methods too.


      Holger