1
Plasma and the Screensaver
2
==========================
4
There are three main pieces to the screensaver picture, two of which involve plasma.
5
first is lockprocess, which manages the other two. second is the [k|x]screensaver binaries which just draw
6
pretty pictures. third is plasma-overlay, which does the plasma stuff.
10
This process manages plasma and the screensaver binaries, and ensures that once the screen is locked
11
it *stays* locked until proper authentication is provided. It provides the unlock dialog too.
12
If a screensaver or plasma-overlay
13
crashes or becomes unresponsive, lockprocess will keep going, ensuring that a locked screen stays locked and can
14
still be unlocked by the user. It's as small as possible to keep the chances of it itself crashing very small.
15
The screensaver binaries are brought in via XEmbed, while communication with plasma-overlay happens
17
lockprocess also filters all keyboard and mouse events, passing them on to plasma-overlay as
18
necessary. if it suspects that plasma-overlay is dead (ie. dbus failure), it won't pass on events,
19
ensuring that the user never ends up with an unresponsive screensaver.
23
This process is a plasma shell; it has a corona and a simple view, and loads its own containment.
24
The containment used by plasma-overlay is very basic; just a customcontainment with a cashew
27
the user can add applets, but not containments. there's configuration for transparency if you have
28
compositing, or wallpaper if not (random wallpaper slideshow is my poor-man's-screensaver). all
29
configuration and applet add/remove are disabled when the screen is locked.
31
it communicates with lockprocess over dbus. lockprocess will send it into an idle mode after a while
32
(where any events trigger the unlock dialog, and plasma-overlay uses a different transparency
33
setting), and tell it to go into active mode when there's activity again. when an unlock action in
34
plasma is activated, plasma-overlay asks lockprocess for permission, and lockprocess will ask the
35
user for their password (or whatever other authentication method).
37
when the screen is locked, plasma-overlay offers two actions to the user: leave screensaver and
38
configure widgets. the first is what you'd expect; you enter your password and all of lockprocess goes
39
away, letting you back into your desktop. the second is more like unlocking widgets in
40
plasma-desktop: it brings you into configuration mode where you can add, remove and configure
41
widgets. this config mode can also be reached from the screensaver kcm module. from config mode you
42
can exit at any time without entering a password; you can also re-lock the screen, of course.
44
if lockprocess vanishes from dbus, plasma-overlay will assume that it missed a signal to quit and
45
will commit suicide. :) this is intentional; I got sick of dbus race conditions leaving me with a
46
plasma-overlay hanging around if I moved the mouse just after the screensaver began to run.
51
Plasmoids on the screensaver obviously present a security risk. this is being minimized as described
52
in the security document.
53
what makes it interesting is that we're less concerned with malicious
54
plasmoids and more with malicious (or mischevious) users; a locked screen left unattended should not
55
end up with goatse on it, or files deleted.
59
* Multi-screen support would be awesome
60
* Plasmify the unlock dialog (either by using plasma theming or by having plasma-overlay run it)