GNOME Bugzilla – Bug 350293
ideas for power management baseline timeout
Last modified: 2006-10-18 19:56:07 UTC
So they aren't lost here are some bits from email with Richard. I've been thinking a bit about how we do the timeout settings. As you know gpm just uses the session idleness as its baseline. I'm no longer sure this is right. One case that we don't handle very well is where we should dim the display. For example, how the Nokia 770 works. You probably want the display to dim much sooner than the session idle timeout period. And you may want the screen to dim but also lock the screen later on. Currently you only have one or the other. So, maybe we should add a new interface for setting a timeout for display dimming? I think there are two obvious ways to do this. 1. Add a (private) interface for only g-p-m to use. 2. Add some kind of generic D-Bus API for setting callbacks to run after a certain idle period. The first is pretty easy and can probably just use gconf. The second is a little trickier maybe. The idea is that the timeout setting policy would be completely controlled by g-p-m since it would obviously be different depending on whether the device is on AC or not, and whether "prefer performance over power savings" is on or whatever. -- Richard Hughes wrote: > On Tue, 2006-08-01 at 13:16 -0400, William Jon McCann wrote: >> Hey, >> >> I've been thinking a bit about how we do the timeout settings. As you know gpm just uses the session idleness as its baseline. I'm no longer sure this is right. > > Hmm, I quite liked the idea myself. > >> One case that we don't handle very well is where we should dim the display. For example, how the Nokia 770 works. > > I think the design is valid. Imagine g-s on 770, after 2 minutes, the > session is idle (the screensaver doesn't go on... :-) and g-p-m dims the > screen. After a further few minutes the screen switches off. > > This is how i've set g-s and g-p-m up on this laptop fwiw. Right, but only way you're able to do this is by disabling screensaver activation and locking. Having to choose power savings over security is not possible for a lot of people. The other problem is that our time resolution for idleness is low. In other words, our lower bound for idleness in g-s is one minute and in g-p-m (last I checked) is also one minute. I think one minute is a reasonable lower bound for idleness - which I see as synonymous with "Mark me as away". However, it probably isn't a good lower bound for trying to save screen power usage when battery is low. >> So, maybe we should add a new interface for setting a timeout for display dimming? >> >> I think there are two obvious ways to do this. >> >> 1. Add a (private) interface for only g-p-m to use. > > Ick. > >> 2. Add some kind of generic D-Bus API for setting callbacks to run after a certain idle period. > > Better, this could be used by lots of other stuff also. > >> The first is pretty easy and can probably just use gconf. The second is a little trickier maybe. >> >> The idea is that the timeout setting policy would be completely controlled by g-p-m since it would obviously be different depending on whether the device is on AC or not, and whether "prefer performance over power savings" is on or whatever. > > Hmm. Never thought of that. So, you can even imagine that g-p-m can be smart about setting the timeout when the battery is low. For instance, drop the display brightness after only a second or two when almost out of battery but when battery is full drop it after say 30 seconds. But the session should not be marked as idle - especially since I can still use the system when the display is dim and I don't want to get kicked off IM or lock my screen. This means that we need a different baseline for g-p-m to use. The next question is whether like the session idle it should still honor g-s inhibitors. My first impression is that it should. So that when I'm playing a game, giving a presentation, or watching a movie the display doesn't keep dimming on me. On the other hand, we should pop up a notification to alert the user that power is low and stuff. Perhaps we need to add a new D-Bus method to g-s and g-p-m to see if we are inhibited or not. Or maybe it is useful to get the list of inhibitors, even if only for debugging. bool IsInhibited() or list GetInhibitors() Maybe GetInhibitors() returns a list of something like: 'Application="APPLICATION";\n Since=SINCE-TIME;\n Reason="REASON";' Which is easily parsed by humans and programs and can be extended later. >> Thoughts? > > For 2.16 everything stays as it is! :-) I'm quite agreeable to making > sweeping changes in 2.17.x Agreed.
So the /apps/gnome-screensaver/power_management_delay can be set by g-p-m based on what it thinks is right. The units are seconds - which is different from the other keys. You probably want to use the idle_delay as a max value for the power_management_delay. Then listen for the SessionPowerManagementIdleChanged(boolean) signal. We can iterate on the names and specific functionality but this is just a first shot. This signal should not be emitted if inhibitted. 2006-10-18 William Jon McCann <mccann@jhu.edu> * data/gnome-screensaver.schemas.in: * src/gs-listener-dbus.c: (send_dbus_boolean_signal), (gs_listener_emit_power_notice), (gs_listener_send_signal_active_changed), (gs_listener_send_signal_session_idle_changed), (do_introspect): * src/gs-listener-dbus.h: * src/gs-monitor.c: (watcher_power_notice_cb), (_gs_monitor_update_from_prefs), (disconnect_watcher_signals), (connect_watcher_signals): * src/gs-prefs.c: (_gs_prefs_set_power_timeout), (gs_prefs_load_from_gconf), (key_changed_cb), (gs_prefs_init): * src/gs-prefs.h: * src/gs-watcher-x11.c: (gs_watcher_set_power_timeout), (gs_watcher_set_property), (gs_watcher_get_property), (gs_watcher_class_init), (remove_power_timer), (add_power_timer), (reset_timers), (_gs_watcher_set_session_power_notice), (_gs_watcher_notice_activity), (power_timer), (idle_timer), (schedule_power_wakeup_event): * src/gs-watcher.h: Add SessionPowerManagementIdleChanged signal for power-management baseline. Fixes #350293
Hey Richard, the last comment was essentially a message to you - I thought you were cc'ed already.
Okay, looks good. So g-p-m doesn't depend on the session being idle to dim, but the session being inactive for a duration. I'm guessing you can't configure this timeout in g-s, and I think it's sane to hardcode this. And we keep the session idle timeout for the inactive sleep stuff. I also think IsInhibited() *and* GetInhibitors() should be implimented by gnome-power-manager and gnome-screensaver - if nothing else then for debugging. Have you got any prototype code for this? I think these will differ little between me and you. And you are really doing some great thing these last few days. Keep up the good work! :-)