screensaver and power manager dbus interfaces

[Holger Macht]

On Fri 02. Jun - 11:48:03, Richard Hughes wrote:
> Okay, my first post to this list, so I hope I'm aiming in the right
> direction.
> 
> gnome power manager :		org.gnome.PowerManager
> gnome screensaver   :		org.gnome.ScreenSaver
> 
> This should probably be cross desktop and less gnome-y as there's no
> reason another program shouldn't just drop in as a replacement for
> either xfce, kde or just a slim-line gnome replacement.
> 
> The interfaces we have now are attached.
> 
> Comments appreciated.

So I also have a few.

> 
> Richard
> 
> -------------- next part --------------
> The GNOME Power Manager DBUS API
> ------------------------------
> 
> This API is currently unstable and is likely to change in the future.
> 
> GNOME Power Manager exposes a DBUS API for programs to obtain
> information about the DPMS state and to change it if required.
> 
> The following constants are used to uniquely refer to the
> PowerManager object when making DBUS method calls:
> 
> DBUS Service:		"org.gnome.PowerManager"
> DBUS Object Path:	"/org/gnome/PowerManager"
> DBUS Interface:		"org.gnome.PowerManager"
> 
> Methods
> =======
> 
> 	Name:		Suspend
> 	Args:		(none)
> 	Returns:	BOOLEAN
> 	Description:	This call will attempt to suspend the system.
> 
> 	Name:		Hibernate
> 	Args:		(none)
> 	Returns:	BOOLEAN
> 	Description:	This call will attempt to hibernate the system.
> 
> 	Name:		Shutdown
> 	Args:		(none)
> 	Returns:	BOOLEAN
> 	Description:	This call will attempt to shutdown the system.

Why do we need this in a power managmenet context. I think all desktop
will provide such a "Shutdown method" via dbus regardless of power
management.

> 
> 	Name:		CanSuspend
> 	Args:		(none)
> 	Returns:	BOOLEAN
> 	Description:	This call Finds if the current user in the session
> 			is able to suspend, and has permission to do so.
> 
> 	Name:		CanHibernate
> 	Args:		(none)
> 	Returns:	BOOLEAN
> 	Description:	This call Finds if the current user in the session
> 			is able to hibernate, and has permission to do so.

How is this ment to be? Does it just a mirror the corresponding HAL
methods power_management.can_hibernate/suspend? If so, I think we don't
need it. Desktops will have a close connection to Hal anyway to query Hal
itself for this information IMHO.

If the Can{Suspend,Hibernate} methods are not meant to state this, what I
think we need is something like...

	AllowedSuspend and
	AllowedHibernate

which is in plain policy context, which means that you are able to
disable/forbid suspend/hibernate from a system administrator point of
view.

At the moment, the corresponding Hal methods just mirror the content of
/sys/power/state.


> 
> 	Name:		setDpmsMode
> 	Args:		STRING
> 			value:	on		100%
> 				standby		<80%
> 				suspend		<30W
> 				off		<8W
> 	Returns:	(nothing)
> 	Description:	DPMS is a standard from the VESA consortium for
> 			managing the power supply of monitors.
> 			This call requests a change in the state of DPMS for
> 			the current screen.
> 
> 	Name:		getDpmsMode
> 	Args:		(none)
> 	Returns:	STRING
> 	Descriptions:	Returns the DPMS mode state.
> 			See setDpmsMode().

Do we really need them? We have the X extensions/functions for that.

[...]

Regards,
	Holger