Re: powerd-dbus network extension
On Tue, Sep 6, 2011 at 4:36 PM, Paul Fox wrote: > - is there anything special about the network inhibit? i wonder if > we should future-proof this by making it a generic > "inhibit-suspend"/"allow-suspend" message? it might have other > uses. but in that case, the requests have to nest correctly. so > maybe something like: > > inhibit-suspend) > : $(( no_suspend++ )) > ;; > > allow-suspend) > : $(( no_suspend = (no_suspend > 0) ? no_suspend - 1 : 0 )) > ;; > > there may be value, though, in knowing who sent the message, if > only for debugging -- that information can be passed as a second > argument on the event. (the first argument should be a timestamp.) Sounds like a good idea to me, so I've implemented this exactly as suggested. > - does powerd-dbus always die correctly and cleanly when powerd dies? Yes, the init system kills it. But I've made this more explicit in exit_actions. New version: http://dev.laptop.org/git/users/dsd/powerd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
daniel wrote: > On Wed, Aug 3, 2011 at 7:07 PM, Daniel Drake wrote: > > Hi Paul, > > > > For 11.3.0 I'd like to implement a solution for the issue where powerd > > idle-suspends while wifi connections are being established, causing > > connection failures and other undesirable activity. > > > > The solution I'm thinking of isn't ideal in that it adds a mini-daemon > > alongside powerd. > > Now implemented, tested and ready for review: > http://dev.laptop.org/git/users/dsd/powerd hi daniel -- thanks for all the work on this. initial thoughts: - is there anything special about the network inhibit? i wonder if we should future-proof this by making it a generic "inhibit-suspend"/"allow-suspend" message? it might have other uses. but in that case, the requests have to nest correctly. so maybe something like: inhibit-suspend) : $(( no_suspend++ )) ;; allow-suspend) : $(( no_suspend = (no_suspend > 0) ? no_suspend - 1 : 0 )) ;; there may be value, though, in knowing who sent the message, if only for debugging -- that information can be passed as a second argument on the event. (the first argument should be a timestamp.) - does powerd-dbus always die correctly and cleanly when powerd dies? paul p.s. i think i eliminated the only instance of this kind of thing by changing the inhibitor to a counter, above, but for the future: i prefer shell booleans to either have (some) value or not: so, for example: network_suspend_ok=true and: network_suspend_ok=; then the test is: if [ "$network_suspend" ] ... > > I didn't go with the rfkill extra in the end - wasn't quite as simple > as I'd hoped. Needs a fresh look, which may even result in it being > fixed elsewhere. > > Thanks, > Daniel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
On Wed, Aug 3, 2011 at 7:07 PM, Daniel Drake wrote: > Hi Paul, > > For 11.3.0 I'd like to implement a solution for the issue where powerd > idle-suspends while wifi connections are being established, causing > connection failures and other undesirable activity. > > The solution I'm thinking of isn't ideal in that it adds a mini-daemon > alongside powerd. Now implemented, tested and ready for review: http://dev.laptop.org/git/users/dsd/powerd I didn't go with the rfkill extra in the end - wasn't quite as simple as I'd hoped. Needs a fresh look, which may even result in it being fixed elsewhere. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
Excerpts from Daniel Drake's message of Wed Aug 03 21:39:55 +0200 2011:
> Good suggestion, I assume you are talking about
> http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html
As mentioned before [1], UPower provides related functionality [2]
that's better suited for automatic power management. Gnome-session seems
to be targeted at manual power management, i.e. explicitly suspending
the machine on a user request (and that's what it actually implements).
At least on Debian, the UPower API is unrestricted, so activities could
start to use it right away. It doesn't fit perfectly (you can only
register DMA latency and network throughput requirements), but better
than nothing. And unlike gnome-session UPower is a system daemon.
powerd-dbus could listen to LatencyChanged('network', ...). Not sure
what it would actually do with the value, though: It's a bandwidth
(Kbps) rather than a latency (µs). Should be worth a try asking the
UPower folks to add another metric, though - especially since one of the
use cases listed in the blog post [3] needs this: "I want my IM
application to request 0.5s latency for messages".
> Unfortunately it would be a lot of work to implement, because
> gnome-session implements this interface. We would have to rebase sugar
> around that.
I already have a patch to use upstream gnome-session instead of the
ancient copy we ship in sugar-toolkit. The only missing piece is API to
trigger Shutdown and Reboot [4] without gnome-session popping up a
dialog. With the upstream gnome-session, we benefit from their
accessibility work (=> automated UI testing).
Sascha
[1] http://lists.laptop.org/pipermail/devel/2010-April/028394.html
[2] http://upower.freedesktop.org/docs/QoS.html
[3] http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/
[4] https://bugzilla.gnome.org/show_bug.cgi?id=575880
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
On Thu, Aug 4, 2011 at 9:20 PM, Paul Fox wrote: > as john suggested in another message, this is yet another > application-specific "protocol" being implemented in powerd, as > a heuristic to keep the user happy. while i have no problem > adding it (what's one more? :-), we should certainly be tracking the > ongoing kernel work which might support all our suspend inhibitors in > a more cohesive way. Agreed. And we're taking a 2-pronged approach to this, with the short-term fix as described in this thread, and our upstreaming work which is a stepping stone towards the long-term fix. I'll start work on the implementation, thanks for your comments! Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
hi daniel -- daniel wrote: > Hi Paul, > > For 11.3.0 I'd like to implement a solution for the issue where powerd > idle-suspends while wifi connections are being established, causing > connection failures and other undesirable activity. > > The solution I'm thinking of isn't ideal in that it adds a mini-daemon > alongside powerd. But hey, you just got rid of HAL, we have breathing > space ;) and I can't think of a better way. > > Here is what I've thought up: > > > Instead of being on-demand and short lived, powerd-dbus will be > launched by powerd and will become a full-time daemon. > In addition to the functionality that it already has, it will connect > to the dbus system bus and monitor NetworkManager's StateChanged > signals. > > The NM states are: > DEVICE_STATE_UNKNOWN = 0 > DEVICE_STATE_UNMANAGED = 1 > DEVICE_STATE_UNAVAILABLE = 2 > DEVICE_STATE_DISCONNECTED = 3 > DEVICE_STATE_PREPARE = 4 > DEVICE_STATE_CONFIG = 5 > DEVICE_STATE_NEED_AUTH = 6 > DEVICE_STATE_IP_CONFIG = 7 > DEVICE_STATE_ACTIVATED = 8 > DEVICE_STATE_FAILED = 9 > > Lets assign a variable: > nm_suspend_ok = state <= 3 && state >= 8 since that can't be true, i assume you meant: nm_suspend_ok = state <= 3 || state >= 8 > (i.e. suspend is only OK if we aren't establishing a connection) > > It will also monitor the wpa_supplicant signals for the same device, > watching for the Scanning signal. > wpas_suspend_ok = !Scanning > > Finally: > suspend_ok = wpas_suspend_ok && nm_suspend_ok you're far more familiar with the details of how NM and wpa_supplicant operate, so i'm sure your proposed conditions are likely correct. > When the suspend_ok flag changes, it would be communicated to powerd > through the powerevents socket, as "network_suspend_ok" or > "network_suspend_not_ok". > > There would be a 2 second settle period after a not-OK to OK > transition before sending the powerd event (and the event would be > aborted if the situation changes within those 2 seconds). This > captures the case where NM says the device is disconnected, and > wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will > initiate a connection immediately after (once it has processed the > scan results). > > When powerd has been told network_suspend_not_ok, it would not suspend > until told otherwise. (I'll probably ask you to implement this bit, I > guess you could do it rather quickly?) sure. as john suggested in another message, this is yet another application-specific "protocol" being implemented in powerd, as a heuristic to keep the user happy. while i have no problem adding it (what's one more? :-), we should certainly be tracking the ongoing kernel work which might support all our suspend inhibitors in a more cohesive way. > > > The above is the main functionality I want to implement. But, to kill > 2 birds in 1 stone, having this full-time daemon around lets me solve > another issue: rfkill. > > You probably recall that sugar-0.84 executed "rfkill block olpc" when > the "disable wifi" checkbox was ticked. Unfortunately this was never it used to be "rfkill block wifi", but perhaps that's changed. > upstreamed (boo), so 11.2.0 doesn't have that functionality. In > 11.2.0, the NM WirelessEnabled property is manipulated, and the > interface is brought down, but we don't actually cut power. > > We do have the option of reimplementing it in Sugar, but (for now) I > think powerd would be a nicer place to do this. (Ultimately, we want > NM to do it). > > So, in addition to the above, powerd-dbus would monitor for > NetworkManager's PropertiesChanged signal, and apply this simple > logic. > > if WirelessEnabled == true: > rfkill unblock olpc > else: > rfkill block olpc again, you're closer to the wireless bits than i am. i guess we know that NM won't be confused by having the card logically disappear when it brings the interface down? if so, then it sounds like a reasonable plan. (though it feels like a bit of a hack for it to be in powerd-dbus.) paul > > > How does this sound to you? > > Thanks, > Daniel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
On Wed, Aug 3, 2011 at 8:39 PM, Daniel Drake wrote: > On Wed, Aug 3, 2011 at 7:48 PM, Peter Robinson > wrote: > > Hi Daniel, > > > > Not sure if powerd makes use of it at all already (for things like > watching > > videos in totem) but why not use the kernel/upower inhibit functionally > just > > like totem and the like does. Then powerd just needs to > > listen/check/whatever for the inhibit and it would then also work (if it > > doesn't already) for those apps like totem in the gnome desktop. > > Good suggestion, I assume you are talking about > http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html > > Apart from totem, what else uses this? NetworkManager doesn't (and > can't, since it is systemwide and this is only for sessions), so it > wouldn't solve the immediatne problem. > > Unfortunately it would be a lot of work to implement, because > gnome-session implements this interface. We would have to rebase sugar > around that. Then we would have to extend upower to support our > idle-suspend model, and somehow get it to replace or play nice with > powerd (because gnome-session calls into upower for this stuff). And > then we'd have to solve the network problem separately anyway... > > Maybe, I thought it was a system wide thing (maybe a freedesktop thing) that was implemented by gnome using gnome-power-manager. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
On Wed, Aug 3, 2011 at 7:48 PM, Peter Robinson wrote: > Hi Daniel, > > Not sure if powerd makes use of it at all already (for things like watching > videos in totem) but why not use the kernel/upower inhibit functionally just > like totem and the like does. Then powerd just needs to > listen/check/whatever for the inhibit and it would then also work (if it > doesn't already) for those apps like totem in the gnome desktop. Good suggestion, I assume you are talking about http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html Apart from totem, what else uses this? NetworkManager doesn't (and can't, since it is systemwide and this is only for sessions), so it wouldn't solve the immediate problem. Unfortunately it would be a lot of work to implement, because gnome-session implements this interface. We would have to rebase sugar around that. Then we would have to extend upower to support our idle-suspend model, and somehow get it to replace or play nice with powerd (because gnome-session calls into upower for this stuff). And then we'd have to solve the network problem separately anyway... Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
Hi Daniel, Not sure if powerd makes use of it at all already (for things like watching videos in totem) but why not use the kernel/upower inhibit functionally just like totem and the like does. Then powerd just needs to listen/check/whatever for the inhibit and it would then also work (if it doesn't already) for those apps like totem in the gnome desktop. Peter On Wed, Aug 3, 2011 at 7:07 PM, Daniel Drake wrote: > Hi Paul, > > For 11.3.0 I'd like to implement a solution for the issue where powerd > idle-suspends while wifi connections are being established, causing > connection failures and other undesirable activity. > > The solution I'm thinking of isn't ideal in that it adds a mini-daemon > alongside powerd. But hey, you just got rid of HAL, we have breathing > space ;) and I can't think of a better way. > > Here is what I've thought up: > > > Instead of being on-demand and short lived, powerd-dbus will be > launched by powerd and will become a full-time daemon. > In addition to the functionality that it already has, it will connect > to the dbus system bus and monitor NetworkManager's StateChanged > signals. > > The NM states are: > DEVICE_STATE_UNKNOWN = 0 > DEVICE_STATE_UNMANAGED = 1 > DEVICE_STATE_UNAVAILABLE = 2 > DEVICE_STATE_DISCONNECTED = 3 > DEVICE_STATE_PREPARE = 4 > DEVICE_STATE_CONFIG = 5 > DEVICE_STATE_NEED_AUTH = 6 > DEVICE_STATE_IP_CONFIG = 7 > DEVICE_STATE_ACTIVATED = 8 > DEVICE_STATE_FAILED = 9 > > Lets assign a variable: > nm_suspend_ok = state <= 3 && state >= 8 > (i.e. suspend is only OK if we aren't establishing a connection) > > It will also monitor the wpa_supplicant signals for the same device, > watching for the Scanning signal. > wpas_suspend_ok = !Scanning > > Finally: > suspend_ok = wpas_suspend_ok && nm_suspend_ok > > When the suspend_ok flag changes, it would be communicated to powerd > through the powerevents socket, as "network_suspend_ok" or > "network_suspend_not_ok". > > There would be a 2 second settle period after a not-OK to OK > transition before sending the powerd event (and the event would be > aborted if the situation changes within those 2 seconds). This > captures the case where NM says the device is disconnected, and > wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will > initiate a connection immediately after (once it has processed the > scan results). > > When powerd has been told network_suspend_not_ok, it would not suspend > until told otherwise. (I'll probably ask you to implement this bit, I > guess you could do it rather quickly?) > > > > > The above is the main functionality I want to implement. But, to kill > 2 birds in 1 stone, having this full-time daemon around lets me solve > another issue: rfkill. > > You probably recall that sugar-0.84 executed "rfkill block olpc" when > the "disable wifi" checkbox was ticked. Unfortunately this was never > upstreamed (boo), so 11.2.0 doesn't have that functionality. In > 11.2.0, the NM WirelessEnabled property is manipulated, and the > interface is brought down, but we don't actually cut power. > > We do have the option of reimplementing it in Sugar, but (for now) I > think powerd would be a nicer place to do this. (Ultimately, we want > NM to do it). > > So, in addition to the above, powerd-dbus would monitor for > NetworkManager's PropertiesChanged signal, and apply this simple > logic. > > if WirelessEnabled == true: >rfkill unblock olpc > else: >rfkill block olpc > > > How does this sound to you? > > Thanks, > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
What kind of idle-suspend are we talking about here (and on what XO hardware)? Shouldn't a proper idle-suspend be resumed when the system isn't idle any more, i.e. when a packet comes in or a timer expires in NetworkManager? Fixing that would eliminate having to build a separate kludge for every time-sensitive protocol. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
powerd-dbus network extension
Hi Paul, For 11.3.0 I'd like to implement a solution for the issue where powerd idle-suspends while wifi connections are being established, causing connection failures and other undesirable activity. The solution I'm thinking of isn't ideal in that it adds a mini-daemon alongside powerd. But hey, you just got rid of HAL, we have breathing space ;) and I can't think of a better way. Here is what I've thought up: Instead of being on-demand and short lived, powerd-dbus will be launched by powerd and will become a full-time daemon. In addition to the functionality that it already has, it will connect to the dbus system bus and monitor NetworkManager's StateChanged signals. The NM states are: DEVICE_STATE_UNKNOWN = 0 DEVICE_STATE_UNMANAGED = 1 DEVICE_STATE_UNAVAILABLE = 2 DEVICE_STATE_DISCONNECTED = 3 DEVICE_STATE_PREPARE = 4 DEVICE_STATE_CONFIG = 5 DEVICE_STATE_NEED_AUTH = 6 DEVICE_STATE_IP_CONFIG = 7 DEVICE_STATE_ACTIVATED = 8 DEVICE_STATE_FAILED = 9 Lets assign a variable: nm_suspend_ok = state <= 3 && state >= 8 (i.e. suspend is only OK if we aren't establishing a connection) It will also monitor the wpa_supplicant signals for the same device, watching for the Scanning signal. wpas_suspend_ok = !Scanning Finally: suspend_ok = wpas_suspend_ok && nm_suspend_ok When the suspend_ok flag changes, it would be communicated to powerd through the powerevents socket, as "network_suspend_ok" or "network_suspend_not_ok". There would be a 2 second settle period after a not-OK to OK transition before sending the powerd event (and the event would be aborted if the situation changes within those 2 seconds). This captures the case where NM says the device is disconnected, and wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will initiate a connection immediately after (once it has processed the scan results). When powerd has been told network_suspend_not_ok, it would not suspend until told otherwise. (I'll probably ask you to implement this bit, I guess you could do it rather quickly?) The above is the main functionality I want to implement. But, to kill 2 birds in 1 stone, having this full-time daemon around lets me solve another issue: rfkill. You probably recall that sugar-0.84 executed "rfkill block olpc" when the "disable wifi" checkbox was ticked. Unfortunately this was never upstreamed (boo), so 11.2.0 doesn't have that functionality. In 11.2.0, the NM WirelessEnabled property is manipulated, and the interface is brought down, but we don't actually cut power. We do have the option of reimplementing it in Sugar, but (for now) I think powerd would be a nicer place to do this. (Ultimately, we want NM to do it). So, in addition to the above, powerd-dbus would monitor for NetworkManager's PropertiesChanged signal, and apply this simple logic. if WirelessEnabled == true: rfkill unblock olpc else: rfkill block olpc How does this sound to you? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
