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.<div> <br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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.</div><div><br></div><div>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).</div> <div><br><div class="gmail_quote">On Tue, May 11, 2010 at 5:10 PM, Dario Freddi <span dir="ltr"><<a href="mailto:drf54321@gmail.com">drf54321@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Tuesday 11 May 2010 16:56:50 Tobias Arrskog wrote:<br> > For 1) I'd say define "idle" as being the abscent of "active". So "ping"<br> > every X seconds when the system is active.<br> > For example, XServer could ping UPower on input changes (mouse movement,<br> > key presses etc.).<br> <br> </div>This definitely belongs to the desktop/whatever is handling powermanagement<br> session wise. You might want to look into XSync to see how you can retrieve<br> the idle time from X - both KDE and GNOME use this (or XSS) to find out about<br> user idle time.<br> <div class="im"><br> > Samba Daemon could ping UPower on active connection.<br> > Session (gnome, kde ...) could ping on IO operations, GStreamer could ping<br> > on playback. PVR Daemons could ping on recording or reading of recording.<br> <br> </div>It's quite unrealistic to get every application signaling stuff to $something<br> (which, however, should not be upower), also because this would come at a<br> cost, which is a lot of wakeups (ironically, this higly impacts on power<br> consumption). The only way to get proper information about idle time is using<br> X, even if this covers only user input.<br> <br> And, as Richard said, there's always inhibition. This is what applications<br> doing lenghty and delicate jobs should use - but watch out for abuse. Your<br> users might end up hating you if they expected their PC to suspend and find it<br> dead after a while instead.<br> <div><div></div><div class="h5"><br> ><br> > As it is now the session, application or daemon need to do this. For<br> > example mythbackend has an idle detection and a user need to supply a<br> > script that tells if it is idle. I would say that this is something that<br> > could be done once and done correct instead of all that needs it do it.<br> ><br> > For 2) perhaps a difference in the level of "active" would apply? for<br> > example a noninterruptable active could never make the machine idle, and<br> > perhaps a screensaver could be regarded as a little active?<br> ><br> > I do agree though that it would be possible to get false idle but I would<br> > say that it would be far simpler in the end if samba could ping that its<br> > active since as it is now the computer would shutdown if set so in gnome<br> > and I don't move my mouse even if a friend streams from my samba share.<br> ><br> > Tobias.<br> ><br> > On Tue, May 11, 2010 at 3:08 PM, Richard Hughes <<a href="mailto:hughsient@gmail.com">hughsient@gmail.com</a>> wrote:<br> > > On 11 May 2010 13:53, Tobias Arrskog <<a href="mailto:topfs2@xboxmediacenter.com">topfs2@xboxmediacenter.com</a>> wrote:<br> > > > When dealing with PowerManagement in XBMC I've noticed that on linux<br> > > > side there really doesn't seem to be a general daemon or manager that<br> > > > can<br> > ><br> > > handle<br> > ><br> > > > if the system is idle or not, this leaves every session to handle it<br> > > > themself.<br> > ><br> > > Two problems:<br> > ><br> > > 1. Define "idle"<br> > > 2. What happens if the computer goes idle (screen power off / server<br> > > powerdown) affects how you define 1).<br> > ><br> > > Richard.<br> <br> </div></div><font color="#888888">--<br> -------------------<br> <br> Dario Freddi<br> KDE Developer<br> GPG Key Signature: 511A9A3B<br> </font><br>_______________________________________________<br> devkit-devel mailing list<br> <a href="mailto:devkit-devel@lists.freedesktop.org">devkit-devel@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/devkit-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/devkit-devel</a><br> <br></blockquote></div><br></div>