[Feature request] PowerManagement and idle detection and powersaving

Tobias Arrskog topfs2 at xboxmediacenter.com
Tue May 11 07:56:50 PDT 2010


For 1) I'd say define "idle" as being the abscent of "active". So "ping"
every X seconds when the system is active.
For example, XServer could ping UPower on input changes (mouse movement, key
presses etc.). Samba Daemon could ping UPower on active connection.
Session (gnome, kde ...) could ping on IO operations, GStreamer could ping
on playback. PVR Daemons could ping on recording or reading of recording.

As it is now the session, application or daemon need to do this. For example
mythbackend has an idle detection and a user need to supply a script that
tells if it is idle. I would say that this is something that could be done
once and done correct instead of all that needs it do it.

For 2) perhaps a difference in the level of "active" would apply? for
example a noninterruptable active could never make the machine idle, and
perhaps a screensaver could be regarded as a little active?

I do agree though that it would be possible to get false idle but I would
say that it would be far simpler in the end if samba could ping that its
active since as it is now the computer would shutdown if set so in gnome and
I don't move my mouse even if a friend streams from my samba share.

Tobias.

On Tue, May 11, 2010 at 3:08 PM, Richard Hughes <hughsient at gmail.com> wrote:

> On 11 May 2010 13:53, Tobias Arrskog <topfs2 at xboxmediacenter.com> wrote:
> > When dealing with PowerManagement in XBMC I've noticed that on linux side
> > there really doesn't seem to be a general daemon or manager that can
> handle
> > if the system is idle or not, this leaves every session to handle it
> > themself.
>
> Two problems:
>
> 1. Define "idle"
> 2. What happens if the computer goes idle (screen power off / server
> powerdown) affects how you define 1).
>
> Richard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20100511/8a61d719/attachment.htm>


More information about the devkit-devel mailing list