Problems with Screensavers and other activity sensitive demons.

William Jon McCann mccann at
Thu Jun 7 08:35:35 PDT 2007

Hi Havoc,

On 6/7/07, Havoc Pennington <hp at> wrote:
> Graeme Gill wrote:
> > "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!)
> >
> While this is hardly the point of your mail ;-)
> It's only a coincidence that the three things are the same in this case,
> essentially because the only object in the screensaver process is a
> global singleton, and the interface on that object has the same name as
> the process.

Yeah.  And that I designed that interface in October 2004 (D-Bus 0.22)... :)

One reason why I encouraged Graeme to post this problem to the list is
that I think we should be able to give him a good answer.  A single
answer, if possible.  In my opinion, the previous messages in this
thread show that we fail both on "good" and "single".

I think that within GNOME the org.gnome.ScreenSaver.Inhibit() [1] has
turned out to be fairly successful.  One use case it doesn't cover is
the ability to inhibit activation/idle per output.  However, it isn't
clear to me that this is particularly useful given that:
a) we made a design decision that the GNOME screensaver would not be
responsible for power management
b) that the primary necessity of a screensaver these days is for
locking the session
c) the screensaver is also generally used as a global session idle
monitor rather than a per-display idle monitor (more like here/away)

That said, I think that power management per output is certainly an
important thing.

Not that this really has much to do with Graeme's problem.  If we had
org.freedesktop.ScreenSaver.Inhibit() that might just do.  However,
the use case we may not be covering perfectly is: "watching a movie on
one output when there are multiple outputs attached and the unused
outputs should save power".



More information about the xdg mailing list