Problems with Screensavers and other activity sensitive demons.

[Graeme Gill]

[William Jon McCann suggested I post a summary of these issues here]

I'm the author of an X11 application for calibrating
and profiling displays. Like some other applications
(ie. slideshow presentations, movie playback) my application
is one in which the user starts, and then doesn't touch
the system while it's running. It may then take some
minutes to an hour or so to complete. Because there is no
keyboard or mouse input, traditional activity cues are missing.
Having a screensaver or power monitor trigger while in the process
of presenting test patches to the screen so that they can
be measured automatically by a spectrometer is a bad thing,
and may then waste a lot of user time.

To avoid this I went to the trouble in my application
of temporarily disabling the screensaver while it is running,
using the documented mechanism under X11 for doing this:
XSetScreenSaver(). It didn't take long to discover that
this in fact was ineffective on the Red Had clone system
I was testing on. Some investigation revealed that
the screensaver favoured by that distribution (xscreensaver)
wasn't playing nice with X11, and in fact was ignoring
the X11 screensaver mechanism. Perusal of the authors
website indicated that he had no interest in fixing this
problem, but merely suggested that application such
as mine run the "xscreensaver-command -deactivate"
periodically. Since there seem no other easy to implement
way of disabling xscreensaver, added a fork() then execlp()
every 60 seconds to do this. Ugly but it worked.

Recently I have had a report from a user indicating that
a screensaver had interrupted calibration of his display.
Enquiry revealed that it was a new screensaver, the
GnomeScreensaver. Perusal of it's web site indicated
that once again, it is not backwards compatible with
the X11 screensaver mechanism, and that it uses yet another
method of control, this time based on D-Bus. While this seems a
little better choice than the xscreensaver approach, the lack
of backwards compatibility is distressing, and the means of
signalling activity so that it doesn't trigger bodes poorly
for future compatibility. It apparently needs a
"dbus-send --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.SimulateUserActivity"
every so often (why does "org.gnome.Screensaver have to be repeated
3 times in the dbus-send syntax ? Surely once is enough!)

This looks bad, as it seems certain that when someone develops
a KDE screensaver, org.kde.screensaver will need signalling,
and when fred develops a new screensaver, com.fred.screensaver will
need signalling etc. And what about power monitoring demons ? Will
they each need to be named and known, and a long list added to
as people add new ones to the operating systems, each time triggering
a flood of support calls for applications such as mine ?

There doesn't seem like there's much system level design going
on here, just each application having to look after itself.

It would be good if D-Bus is to be the channel for it,
that there was one central entity that has to be signalled
to indicate activity, rather than signalling each application
interested in activity individually.
It would also be good if the screensavers could hook into
the existing X11 screensaver mechanism, so that existing
applications don't break either.

My application is cross-platform, and solving the screensaver
problems on MSWindows and OS X was not anywhere as complicated
(SetThreadExecutionState(ES_DISPLAY_REQUIRED),
and UpdateSystemActivity(OverallAct) respectively.)

Hopefully this feedback may trigger some proposals to solve
these sorts of problems in a more elegant way than at present.

Graeme Gill.