[Utopia] power mgmt in GNOME; requirements?

[David Zeuthen <david fubar dk>]

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