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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
