[Feature request] PowerManagement and idle detection and powersaving
Paul Fox
pgf at laptop.org
Tue May 11 09:26:25 PDT 2010
i'm interested in this topic as well, as the author of the powerd
daemon that controls sleep, idle-suspend, and the screen on the
XO laptop these days.
a few of semi-random comments from my perspective:
- this comment of richard's is spot on:
> 2. What happens if the computer goes idle (screen power off
> / server powerdown) affects how you define 1).
on the XO, for instance, we can put the laptop to sleep
while preserving the contents of the display. deciding when
it's not okay to do this, in the absence of obvious
indicators like user input, is tricky, and is a decision
that most systems don't need to make.
- there's no reason for the "ping" operation that tobias
describes to go across the dbus. a simple filesystem
rendezvous is quite sufficient. the inhibit of suspend
isn't an event by nature -- it's a state. on the XO i'm
trying pretty hard to come up with heuristics based on cpu,
network, and device utilization that obviate the need for
every application to inhibit separately, and so far have
been reasonably successful. but if they need it, an app
simply creates a file named after its PID in a known dir
under /var/run, and we won't suspend if that directory is
non-empty. (it cleans out files whose owners are no longer
alive.) an app can also inhibit suspend by "touching" a
known file periodically. both of these mechanism are
essentially free in terms of processing, and power.
- in my opinion. the VT consoles, and other non-X interfaces,
are becoming second and third class citizens far too
quickly. basing user input decisions on X idleness is the
wrong technique, in my opinion.
this is all from the perspective of someone approaching the
problem on a very specific product: a single-user (this is
important) system with somewhat unique interface characteristics.
i can imagine that our solution might not solve everyone's
problem, but that's also partly my point: i think it's
unreasonable to expect the solutions that handle a (possibly
multi-user) desktop workstation to match those needed on an
embedded NAS box or a DVR system. what's needed is a flexible,
preferably scriptable, framework.
paul
tobias wrote:
> I see this from XBMC standpoint which is able to be a session or just an
> application, we flag when its session so its no biggie to know when to
> handle it. however, this means that if XBMC is not in charge of it we need
> to see if we have KDE, Gnome etc. etc. underneath to report to. This
> complicates stuff somewhat and makes it highly unlikely to be implemented by
> a daemon. I know xbmc is not alone in this regard as tvheadend (dvr daemon)
> does not have any power handling since there is no system wide, standardized
> daemon to report to, if there was they would but they don't want to check
> for every possible session daemon out there, which IMO is understandable.
>
> Anyways, the ping idea was merely one way to do it, if its considered
> traffic intense inhibit is equally good except if the application that
> inhibited crashes. But I did not think of the power consumption, so inhibit
> is probably better I agree.
>
> IMO any app that inhibits or tells session that its not idle could extremely
> easy report to a system wide version instead, but since there exist only one
> to report to its much more likely that applications or daemons will report
> to it. If a daemon, like samba, does not report to the system daemon nothing
> has changed it doesn't report to the session deamon as it is now so its not
> like anything have changed in this regard. Afaik this is how any of the
> other bigger operating system works, granted they only have one session to
> begin with.
>
> And if the computer suspend on user-idle and had no samba connection when
> suspending, the system did IMO a correct thing, it was fully idle when
> suspending.
>
> I won't argue if you guys disagree, as a user that sets up a NAS that I want
> to powersave I see this as a big problem and something that could have
> easily been solved if there was a system wide daemon. In this even Xss won't
> work since active is not when input reacts, it never will do, but when
> samba, dvr or the mailserver do something. What I want to come down to is
> that I really don't see how its the sessions job to handle the systems
> power, especiall since its plausible to have more than one session (granted
> you never will do powersave on a multisession system).
>
> On Tue, May 11, 2010 at 5:10 PM, Dario Freddi <drf54321 at gmail.com> wrote:
>
> > On Tuesday 11 May 2010 16:56:50 Tobias Arrskog wrote:
> > > 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.).
> >
> > This definitely belongs to the desktop/whatever is handling powermanagement
> > session wise. You might want to look into XSync to see how you can retrieve
> > the idle time from X - both KDE and GNOME use this (or XSS) to find out
> > about
> > user idle time.
> >
> > > 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.
> >
> > It's quite unrealistic to get every application signaling stuff to
> > $something
> > (which, however, should not be upower), also because this would come at a
> > cost, which is a lot of wakeups (ironically, this higly impacts on power
> > consumption). The only way to get proper information about idle time is
> > using
> > X, even if this covers only user input.
> >
> > And, as Richard said, there's always inhibition. This is what applications
> > doing lenghty and delicate jobs should use - but watch out for abuse. Your
> > users might end up hating you if they expected their PC to suspend and find
> > it
> > dead after a while instead.
> >
> > >
> > > 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.
> >
> > --
> > -------------------
> >
> > Dario Freddi
> > KDE Developer
> > GPG Key Signature: 511A9A3B
> >
> > _______________________________________________
> > devkit-devel mailing list
> > devkit-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/devkit-devel
> >
> >
> part 2 text/plain 168
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel
=---------------------
paul fox, pgf at laptop.org
More information about the devkit-devel
mailing list