Hi, and sorry for the cross-posting.
This mail represents some of my thoughts about what level of power management the GNOME desktop should expose. I will only try to describe high-level programmatic interfaces as well as high-level UI elements. Much of this work is already happening in gnome-power by Richard Hughes so this is mostly a discussion of (important?) details. BACKGROUND So, for a good idea of what Mac OS X and Windows does in this space, see this part of the X vs. XP site http://www.xvsxp.com/power/ which is indispensable as background information. HIGH-LEVEL REQUIREMENTS To start, the term "power management" doesn't really adequately cover all the linked-together parts that I'd like to include. Specifically, the already existing today screen saver bits needs to be factored in here. So, here's a short list of high-level requirements with a sample of (obvious?) use-cases as second-level bullets. o Track all devices attached system - can easily get this from HAL (batteries, UPS'es, mice..) - warn about low battery status o Track when the user is idle (and inform other apps) - applications can do batch processing when user is idle - downloading email messages (evolution) - rebuilding indexes (updatedb, makewhatis) - rearranging sectors for optimized boot etc. o Track whether system isn't running on mains (and inform other apps) - applications can select low-cost CPU and IO paths - Totem selecting a low-cost video codec (CPU) - updatedb not happening (IO) - evolution not downloading all my email messages (IO) o Enforce actions according to user preferences - we want to invoke screensaver / lock the screen / suspend the display / suspend system when user is idle - power down system when UPS battery is near depletion o Provide mechanishm for apps to veto actions / do book-keeping before an action is to be performed - gaim, evolution can shut down connections gracefully before going into suspend / shutting down (since network is going anyway) - Totem (when playing a movie) / OpenOffice Impress (when doing a presentation) can say "always keep display visible" which translates into "never suspend display or system" etc. (this is a convenient special case of vetoing a number of actions) o User Interface - capplet in gnome-control-center for end-user preferences (emphasis on end-user (!)) - gconf keys for preferences we don't want to expose to the end user - someone may build a GNOME Power Toy style app for controlling this though - something sitting in the GNOME panel providing feedback / shortcuts to common actions (see USER INTERFACE below) REQUIREMENTS FOR THE PROGRAMMATIC INTERFACE So, the idea is a single session-wide daemon, gnome-power-manager, that exports a D-BUS object with an interface that has an API somewhat similar to this: - Methods: - bool isUserIdle () - bool isRunningOnMains () # Used for saying "always keep display visible" by an app - void displayAlwaysVisibleRef () - void displayAlwaysVisibleUnref () # used for signing up for vetoing a specific action; returns # vetoerId - int vetoActionRegister (string localizedAppname, array{byte} icon) # g-p-m will automatically unregister vetoers that disconnect from # the bus - void vetoActionUnregister (int vetoerId) # Vetoer allows a specific action to take place - int vetoACK (int vetoerId, int actionId) # Vetoer doesn't allow a specific action to take place; g-p-m SHOULD # display a notification to the user that the action cannot take # place and what the vetoing application is - int vetoNAK (int vetoerId, int actionId, string localizedReason) # Vetoer asks for a timeout of N ms before g-p-m should try to # perform the action again. It is legal for the vetoer to call # vetoACK before the timeout. # If the (accumulated) delay amounts to more than one second g-p-m # SHOULD display a notification about who is blocking the action - int vetoWait (int vetoerId, int actionId, int timeout, string localizedReason) - Signals # emitted when the mains power connection changes - mainsStatusChanged (bool isRunningOnMains) # emitted when the use is idle / no longer idle - userIdleStatusChanged (bool isIdle) # registered vetoers (vetoActionRegister) MUST respond to this # signal using vetoACK, vetoNAK, vetoWait with ten seconds otherwise # they are kicked out as vetoers (to work around locked-up apps) # action is one of: 'invoke-screensaver', 'suspend-display', # 'suspend-system', 'hibernate-system', # 'power-off' - actionAboutToHappen (int actionId, string action) - performingAction (string action) This interface can probably be improved; no need to discuss the specifics here. I'd like to keep this as simple as possible, but still sustain the high-level requirements as stated above, because this is the interface I'd like GNOME applications to use. The programmatic interface for how gnome-power-manager enforces these actions and gets it's information is right now an implementation detail and discussion of this is probably not worthwhile at this point (though readers will know that this right now includes HAL etc.) The configuration is to be read from the gconf database at a unique location (such as /desktop/gnome/power_manager), thus meaning we can leverage all those features (lock down, per user). It doesn't make sense yet to specify the schema - we need to get the UI right in order to do that. REQUIREMENTS FOR THE USER INTERFACE OK, so this is perhaps the most controversial part cause everyone here is a UI expert :-)... Here's my list of UI features to include - to be fair it's just a mixture of what X and XP does o g-p-m should be implemented as a desktop-session daemon that is always available - it uses the notifcation area to provide an icon (though not always visible, see below) to communicate state and shortcuts to the user This is IMO much preferred to using an applet since a) an applet (normally) has per-instance preferences; b) isn't necessarily added by default; c) it doesn't make sense to have two instances of g-p-m running; d) some vendors like the fact that it is easily usable in other desktop environments. o End user settings are available in preferences capplet in gnome- control-center plus available as a shortcut from the icon in the notification area (though some distros may choose not to include it in gnome-control-center) o The end-user preferences capplet should include the following - Timeout for when screen saver kicks in - Timeout for when display is blanked - Timeout for when the system suspends - Timeout for when the system hibernates - When and if to shut down when running on UPS power - Timeout for when hard disks are spinned down o The end-user preferences capplet should only reflect the entities and actions that makes sense to the system - e.g. don't show hibernate option if the system can't hibernate - don't show UPS UI if no UPS is attached - and so on.. o The end-user preferences capplet should have the notion of profiles only if there is more than one power source - running on mains / running on laptop battery / running on UPS o The end-user preferences capplet should NOT have the notion of preset settings such as "Highest Performance", "Longest Battery Life", "DVD Playback", "Presentations" - we can write software to figure this out / solve this (e.g. the Linux kernel doesn't give the option to "boost" the priority of the process that has a foreground window either :-) - this is open source; we can modify the applications at will to use earlier mentioned programmatic interface o The end-user preferences capplet should have a single check-box whether an icon is display in the notification area o the g-p-m policy for displaying icons in the notification area should not be configurable (except for the single check-box mentioned above); the policy should be - at all times, only display no more than a single icon - only show an icon if the system got either a 1) laptop battery; or b) an UPS battery. - Display the level for the battery / whether we are charging (notibat style) - Specifically, do not display the power level of peripheral devices (mice, PDA's,...) in the notification area - when an app uses the "always keep display visible" facility (displayAlwaysVisibleRef()) let the icon show this and allow the user to override o g-p-m should display "low battery warning" notifications - even for peripheral devices (mice, PDA's,...) IMPLEMENTATION DETAILS I'll briefly touch this o g-p-m should get it's information from HAL - though this should be in a single C file so OS'es not using HAL can implement this themselves (non-Linux OS'es comes to mind) o g-p-m should be written in C to keep the memory requirements at a minimum (/me mumbles about the size of the python GNOME/ GTK+ stack) as it's intended to run all the time. o ideally g-p-m should use the new and totally sweet glib/gobject bindings available today as the proposed D-BUS API is very simple (the bindings should be able to cope with this today) o with time (shortly!), HAL will provide appropriate interfaces for enforcing policy; e.g. export an interface with the methods such as Suspend(), Hibernate(), SuspendDisks() as well as keys such as power_management.can_suspend and .can_hibernate. Distributions will be able to easily plug into this to provide their own suspend scripts / read from existing conf files whether the system can suspend, hibernate etc. o Ideally, we'd use the bubble notification API a'la http://www.gnome.org/~clarkbw/blog/GNOME/I_got_your_notification_right_here_pal until then we need to use modal dialogs... o We need to change the GNOME preferences capplet for xscreensaver; specifically remove the setting of timeout and the display power management since that is going to be taken care of by g-p-m. We may even combine the xscreensaver and power-preferences capplets; I don't know.. Oh well, this mail turned out a bit longer that I expected. I'll follow up with a mail on the sesion-wide vs. system-wide details later. If you want to follow up on several areas (programmatic interface, user interface, implementation goals) please do that in several individual mails. Ideally, this is something we should do for GNOME 2.12. Cheers, David -- David Zeuthen: david fubar dk - davidz redhat com inactivity log: http://blog.fubar.dk _______________________________________________ utopia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/utopia-list
