[Feature request] PowerManagement and idle detection and powersaving
Hi! 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. Since XBMC is meant to work equally good on both with and without a system we need to handle it ourself but want to let the session if existant to handle it for that native feeling, this means checking all available daemons, which is abit cumbersome. So my question being wouldn't it be nice if UPower could be used to handle this? Basically any application could send SetActive or SetInActive or SetIdle, SetActive.. More or less the QoS extended I guess?. This would allow daemons to have a generic place to set active if needed, say samba daemon could set active easily if another user downloads data, or tvheadend (pvr recorder) to set active if needed. I guess the PowerManager could handle idle actions aswell (like powerdown) or just signal them and let anything else handle it. If UPower doesn't want to handle the actual actions on idle (shutdown, suspend etc.) could use the network manager way and letting a session tool connect and be used. Not sure which you guys find the best? Personally I would have appreciated such a tool as it would make it much easier for us to integrate with systems underneath and would make home servers like NAS able to nicely know when they safely could power save without knowing if and what session is used. Is this something planned or an idea that more than I would like to have? Cheers, Tobias ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [Feature request] PowerManagement and idle detection and powersaving
On 11 May 2010 13:53, Tobias Arrskog 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. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [Feature request] PowerManagement and idle detection and powersaving
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 wrote: > On 11 May 2010 13:53, Tobias Arrskog 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. > ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [Feature request] PowerManagement and idle detection and powersaving
On 11 May 2010 15:56, 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. That sounds like a _lot_ of extra traffic on the bus. > 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. If I suspend on user-idle then samba is no longer able to process requests from my friend. I think the inhibit API's we have in the session right now cope well from a complexity / bus traffic point of view and it's highly likely you want to hook into that for XBMC. Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [Feature request] PowerManagement and idle detection and powersaving
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 wrote: > > On 11 May 2010 13:53, Tobias Arrskog 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 signature.asc Description: This is a digitally signed message part. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [Feature request] PowerManagement and idle detection and powersaving
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 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 > wrote: > > > On 11 May 2010 13:53, Tobias Arrskog > 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 pow
Re: [Feature request] PowerManagement and idle detection and powersaving
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 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/w
