screensaver and power manager dbus interfaces

[Oswald Buddenhagen]

On Wed, May 31, 2006 at 11:01:31PM +0100, Richard Hughes wrote:
> gnome power manager :		org.gnome.PowerManager
> gnome screensaver   :		org.gnome.ScreenSaver
> 
ok, here are some random thoughts from the "kdm guy".

we are talking about several things:
1) screen saver
2) dmps (display power states)
3) system power states
each of them having mechanism and policy aspects.

1) and 2) share common sensors (a) and a common policy (b). directly
attached to them is the screen locker as one "policy enforcement
device". from the actuator side (c), they are completely different: 1)
is a pure application thing, 2) is a driver thing. x tries to do 1a and
2a-c, and you won't get around using it to some degree if it is the
underlying graphics system.
1) and 2) are a purely in-session thing and should share one api, as far
as i'm concerned.

3) is an entirely different animal. it is a _system_ thing, as it
concerns everybody, including remotely logged in users and services.
hibernate/suspend are different from halt/poweroff/reboot only in that
they "only" interrupt local user sessions instead of terminating them.
the sensor side includes manual action and daemon activity (timers,
power supply monitors, cpu usage monitors, etc.). the actuator side are
system command calls. the policy part is a *very* interesting one. apart
from static permission checks, one can add timing constraints, integrate
with batch processing systems, ... in short, the possibilities are sort
of endless.
the only connection to 1+2 is activation of the screen locker upon
resuming, but in principle that's only an implementation detail.

here's some things i've done or plan to do regarding 3):
- kdm has simple allowed/not allowed permissions for
  - system shutdown
  - forcible termination of foreign sessions
- kdm has delayed shutdown when sessions are still running, with enforce
  and give up option upon a timeout
- completely timed shutdown is planned.
- i'm using a script that integrates atd with sysvinit's shutdown
  related commands and nvram-wakeup (a tool to let the rtc clock power
  up the system). this should be integrated with kdm, so the user gets
  sensible feedback when he tries to shut down but the system simply
  refuses to do so.  bottom line is, that this is a shutdown policy
  source.
- to accomodate the sheer unlimited policy possibilities even on
  manually initiated shutdowns, i plan to introduce "shutdown profiles"
  which would be selected instead of the regular shutdown/reboot
  options and optionally parametrized (shutdown timeout, etc.).
- to accomodate daemon-based policies, i considered using a script that
  would communicate over kdm's control socket - i suppose a dbus service
  would do as well.

on a related note, i'm planning to melt the screen locker into kdm to
allow smoother fast user switching, reuse of the greeter theming from
kdm and vice versa to have dpms and screen saver support in kdm.
for this to succeed, i would need the 1+2 service (idleness detection,
dpms vs. screensaver activation policy, screen saver invocation)
runnable and configurable in "no-user" context (well, it runs as root
(currently) and we have a $HOME (in /tmp). the configuration is a big
question though, especially as kdm has a really interesting system for
per-display settings (x resources like)).

i don't feel like making concrete plans, as i won't have time to put
them into practice for the next months anyway.
but feel free to evaluate this input and possibly even make some head
and tails of it. ;)
the important part is not to provide everything i might need (even
though it would be nice ;), but not to put stones in my way.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.