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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
