Comment 33 for bug 428884

I have further studied the gnome-screensaver code, and have come to the conclusion that the SimulateUserActivity functionality (this is what vlc and 'gnome-screensaver-command --poke' actually call inside g-s-s) is left simply broken.

As shown in comment #15, SimulateUserActivity asks the unlock screen to appear, but will (no longer) prevent the screen to be locked. This makes this functionality absolutely unusable for any media player application.

Xtophe points out that g-s-s is supposed to proxy requests to gnome-session. This is right, but only when using the Inhibit API.

Patching vlc to use Inhibit instead of SimulateUserActivity would be an option. However, the API is different. While SimulateUserActivity does not require any parameters, Inhibit requires three: the application name, the reason for inhibiting and a random (but unique) cookie. Currently, vlc/modules/misc/screensaver.c does support dbus calls without parameters only. And since here the low level dbus API is used, adding this is hard for me. DBUS gurus welcome. Perhaps it would be easier if that file was ported to glib so that the glib dbus bindings could be used. YMMV.

For similar reasons gnome-screensaver is uneasy to fix. It would have to somehow identify what application has poked the screensaver, invent some reason for inhibiting the saver and decide on a duration how long the supression should last.

IMO improving g-s-s to proxy the SimulateUserActivity call to the inhibit API would make it most compatible with existing applications. At least this change should be properly communicated to upstreams who now wonder why poking the screensaver suddenly fails.