After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 579430 - poke command not working?
poke command not working?
Status: RESOLVED WONTFIX
Product: gnome-screensaver
Classification: Deprecated
Component: general
2.28.x
Other Linux
: High major
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
: 639680 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-18 17:18 UTC by matthias koplenig
Modified: 2013-03-08 16:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30


Attachments
Patch to apply to gs-monitor.c (883 bytes, patch)
2009-10-08 14:05 UTC, Corentin
none Details | Review
Re-introduce legacy screensaver inhibit (4.12 KB, patch)
2009-12-22 01:00 UTC, Chris Coulson
none Details | Review
Reintroduce legacy API for inhibiting the screensaver (996 bytes, patch)
2010-12-07 05:57 UTC, Dylan Smith
none Details | Review

Description matthias koplenig 2009-04-18 17:18:53 UTC
i'm playing movies/dvds with mplayer, however since there isn't a command to disable the screensaver my session idles all the time.

using >gnome-screensaver-command -p< as a heartbeat-cmd, which is executed every 30 seconds _faking_ user-activity, used to work in 2.24.

the debug log lists quite a lot of these messages:

-- snip --
[listener_service_deleted] gs-listener-dbus.c:1049 (18:56:57):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (18:56:57):	 DBUS service deleted: 
[gs_manager_request_unlock] gs-manager.c:1782 (18:56:57):	 Request unlock but manager is not active
[listener_service_deleted] gs-listener-dbus.c:1049 (18:56:57):	 DBUS service deleted: :1.184
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:03):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:03):	 DBUS service deleted: :1.185
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:27):	 DBUS service deleted: 
[gs_manager_request_unlock] gs-manager.c:1782 (18:57:27):	 Request unlock but manager is not active
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:27):	 DBUS service deleted: :1.186
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:57):	 DBUS service deleted: 
[gs_manager_request_unlock] gs-manager.c:1782 (18:57:57):	 Request unlock but manager is not active
[listener_service_deleted] gs-listener-dbus.c:1049 (18:57:57):	 DBUS service deleted: :1.187
[listener_service_deleted] gs-listener-dbus.c:1049 (18:58:27):	 DBUS service deleted: 
[gs_manager_request_unlock] gs-manager.c:1782 (18:58:27):	 Request unlock but manager is not active
-- snip --
Comment 1 Artyom Smirnov 2009-09-08 19:15:59 UTC
Confirming same behaviour.
Comment 2 Artyom Smirnov 2009-09-08 19:16:55 UTC
Also same bugreport in debian http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg681088.html
Comment 3 Sven Arvidsson 2009-09-08 19:36:43 UTC
Not surprising as that function has been replaced with a FIXME ;)
Comment 4 Corentin 2009-10-08 14:05:34 UTC
Created attachment 145050 [details] [review]
Patch to apply to gs-monitor.c
Comment 5 Artyom Smirnov 2009-10-14 01:51:20 UTC
Hmm, do not know why, but patch not working when mplayer is running.
Comment 6 Christophe Mutricy 2009-10-15 22:18:46 UTC
I have tested Corentin's patch on Debian Sid  with vlc and it works very well.

(packages at http://people.videolan.org/~xtophe/debian and in motumedia's PPA for people wanting to test)
Comment 7 Artyom Smirnov 2009-10-16 01:59:30 UTC
(In reply to comment #6)
> I have tested Corentin's patch on Debian Sid  with vlc and it works very well.
> 
> (packages at http://people.videolan.org/~xtophe/debian and in motumedia's PPA
> for people wanting to test)

But VLC is not MPlayer, right? :)
Comment 8 Christophe Mutricy 2009-10-16 12:42:42 UTC
Indeed. But that demonstrate VLC is superior.



Troll apart, could you check the code or the activity on Dbus (with e.g. bustle-dbus-monitor) and see if mplayer is sending Poke or SimulateUserActivity ?

If it sends only Poke, it's mplayer's fault.
Comment 9 Corentin 2009-10-17 12:15:36 UTC
For mplayer i use heartbeat-cmd.
Just put:
heartbeat-cmd="gnome-screensaver-command -p"
in ~/.mplayer/config and mplayer call poke every 30 second.
Comment 10 Reinhard Tartler 2009-10-18 19:22:49 UTC
see https://bugs.edge.launchpad.net/gnome-screensaver/+bug/428884/comments/28 for a short review of the patch. Relevant comment:

21:15:07 < chrisccoulson> siretart - i'll have a look if i get
   the chance, but the patch doesn't really look right anyway.
   gnome-screensaver currently gets session idle-ness from
   gnome-session, which uses the SYNC extension and IDLETIME
   counter. applications which want to inhibit the screensaver
   should really be the gnome-session inhibit API now, although
   it would be nice to get gnome-screensaver to work correctly
   too
Comment 11 Reinhard Tartler 2009-10-20 22:42:29 UTC
copying my analysis from https://bugs.launchpad.net/gnome-screensaver/+bug/428884/comments/33:

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.
Comment 12 ForgivenByJC 2009-11-23 15:24:32 UTC
Why does the status of this remain unconfirmed?
Comment 13 michal 2009-11-23 19:01:52 UTC
I see this bug too.

Here's a workaround.

Save everything after the -----'s as sendXshift.c

then compile with:
	cc -o sendXshift sendXshift.c -lX11 -lXtst

Put the program, sendXshift somewhere in your path: /usr/local/bin perhaps, and
then use it as your mplayer heartbeat command.

This program simulates the press of a shift key when it is run.
While it seems conceivable that a shift press/release could do something unwanted, it seems pretty unlikely...

---------------------
/* program to send shift-down, shift-up through X test extension
   to indicate that the X session isn't idle */

#include <stdio.h>
#include <stdlib.h>

#include <X11/Xlib.h>
#include <X11/extensions/Xext.h>
#include <X11/extensions/XTest.h>

int main(){
  Display *dpy;
  Status stat;
  int i1,i2,i3,i4;
  Bool stat1;

  dpy = XOpenDisplay(NULL);

  if (dpy == NULL){
    printf("open display failed\n");
    exit(1);
  }

  stat1 = XTestQueryExtension(dpy,&i1,&i2,&i3,&i4);
  if (stat1 == 0){
    printf("Xtest not supported\n");
    XCloseDisplay(dpy);
    exit(1);
  }
  // shift down:
  XTestFakeKeyEvent(dpy,0x32,True,CurrentTime);
  // shift up:
  XTestFakeKeyEvent(dpy,0x32,False,CurrentTime);

  XCloseDisplay(dpy);


}
Comment 14 Jeremy Nickurak 2009-12-05 21:35:11 UTC
Importance->High, regression.
Comment 15 Chris Coulson 2009-12-22 01:00:43 UTC
Created attachment 150211 [details] [review]
Re-introduce legacy screensaver inhibit

Here is a preliminary patch, which I'm just about to upload to Ubuntu. The patch uses XTest to reset the IDLETIME count, and the code is borrowed from totem-scrsaver.c in totem.

I appreciate this is legacy functionality in gnome-screensaver and the correct way of inhibiting the screensaver in GNOME is by using inhibitors, but xdg-screensaver currently wraps this legacy API in gnome-screensaver and lots of cross-desktop applications (eg, VLC) still rely on this functionality to exist.
Comment 16 Jeremy Nickurak 2010-01-12 00:55:02 UTC
I should point out that the patch ubuntu recieved has been backed-out as it broke other things, so there is no workaround or patch available that effectively restores gnome-screensaver to a working state.
Comment 17 Jeremy Nickurak 2010-01-22 06:58:50 UTC
Relevent comments:

"MythTV will not be patched.  gnome-screensaver advertises --poke for
suspending even in it's --help.  It's what xdg-screensaver uses.  The
root of the problem is in gnome-screensaver itself."


Quite right:

"  -p, --poke                 Poke the running screensaver to simulate user activity"

It's inappropriate for gnome-screensaver to have rescinded this feature so quickly without notice to application developers that they need to follow a different means of interacting with it. *Especially* when gnome-screensaver still documents this as the right way to go.

This regression is a major loss of functionality, as it clearly interferes with the operation of other applications. Setting severity appropriately, updating versions.
Comment 18 Jeremy Nickurak 2010-02-03 22:14:47 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=25855 suggests a x-server-side solution for the KDE screensaver. Is this the correct change for gnome's side as well?
Comment 19 Dylan Smith 2010-12-07 05:57:16 UTC
Created attachment 175988 [details] [review]
Reintroduce legacy API for inhibiting the screensaver

(In reply to comment #18)
> https://bugs.freedesktop.org/show_bug.cgi?id=25855 suggests a x-server-side
> solution for the KDE screensaver. Is this the correct change for gnome's side
> as well?

The server side fix allows XResetScreenSaver to be used to simulate user activity again, which appears to be the correct way to implement --poke. The attached patch is currently being used by Ubuntu, and I have applied it to fix the bug on Debian.
Comment 20 Pacho Ramos 2011-02-07 11:52:37 UTC
Could gnome-screensaver devs explain the way to go?
1. Reintroduce poke
2. Ask mplayer and co. people to fix their apps

Thanks
Comment 21 William Jon McCann 2011-03-06 07:08:21 UTC
2. Fix the apps to use the Inhibit interface on the SessionManager object.

Poke was only supposed to be a temporary transition to using Inhibit and well we know how temporary goes sometimes. :)
Comment 22 michal 2011-03-06 07:18:16 UTC
Could it at least not still advertise that poke should work?

In gnome-screesaver-2.30.2, gnome-screensaver-command -h still lists:
-p, --poke  Poke the running screensaver to simulate user activity
Comment 23 William Jon McCann 2011-03-06 07:41:06 UTC
*** Bug 639680 has been marked as a duplicate of this bug. ***
Comment 24 Reinhard Tartler 2011-03-06 09:37:52 UTC
please elaborate how you envison plain C, non glib using applications to implement the inhibit interface. Currently, using dbus is such a configuration is non-trivial, to use friendly words.
Comment 25 Timo Hoenig 2011-03-06 10:09:03 UTC
Reinhard, you can use the D-Bus C bindings for this.  While not very attractive to use you'll solely pull a single dependency to libdbus when going for this approach.

According to the initial bug report this discusses mplayer as a use case.  At least on my system mplayer already links against D-Bus.  Following Jon's advise by /using/ Inhibit on org.gnome.SessionManager is the way to go.  From looking at the documentation at 

* http://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html#gs-method-Inhibit

it sounds pretty straight forward.  Run mplayer, call Inhibit when starting playback (-> cookie), Uninhibit when stopping playback using the cookie.

For this you don't even have to hook into mplayer's main loop as you are not required to provide a D-Bus interface or receive signals.
Comment 26 graysky 2011-03-06 13:58:10 UTC
Looks like we're going no where with this:

http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1887

Quote - MPlayer will _not_ implement gnome-specific stuff. Unless the gnome developers get their act together and support at least one gnome-independent method gnome will not be supported. This is _final_.

It is ridiculous to expect every single application to support your special way
that in addition is changed at least once a year, we will not play along with
these incompetent games of "look, we came up with a new idiocy to waste your
time with".

end quote
Comment 27 Timo Hoenig 2011-03-06 14:39:20 UTC
(In reply to comment #26)

> Looks like we're going no where with this:

Nod.

Two times WONTFIX means stagnation for the time being.
Comment 28 graysky 2011-03-06 16:26:26 UTC
Not so ugly work around is to use caffeine: https://launchpad.net/caffeine
Comment 29 Josselin Mouette 2011-03-06 16:45:45 UTC
(In reply to comment #26)
> Quote - MPlayer will _not_ implement gnome-specific stuff. Unless the gnome
> developers get their act together and support at least one gnome-independent
> method gnome will not be supported. This is _final_.
> 
> It is ridiculous to expect every single application to support your special way
> that in addition is changed at least once a year, we will not play along with
> these incompetent games of "look, we came up with a new idiocy to waste your
> time with".
> 
> end quote

This kind of reaction (apart from the douchebag tone) was expected at the minute it was decided to go with a GNOME-specific DBus interface for session management instead of getting it standardised in freedesktop.
Comment 30 Timo Hoenig 2011-03-06 17:05:37 UTC
Re comment 28:  Using another screensaver is also an option.  Then we can stop discussing once and for all :-)

Re comment 29:  Yes, this reaction definitely does not set the right tone.  Without having looked into mplayer I'd expect this to be doable with ~ two dozen lines of code given that it already links against D-Bus.  But assuming the developer's decision to be final, this doesn't help either.

Any particular reason this hasn't been changed to org.freedesktop.ScreenSaver?  Ultimately it works quite well in other areas (NetworkManager, PackageKit, and D-Bus ;-)
Comment 31 Milan Bouchet-Valat 2012-02-23 14:01:09 UTC
OK, three years later the situation is still blocked:
- VLC[1] and MPlayer[2] don't want to implement GNOME-specific D-Bus calls
- they'd like to use freedesktop.org D-Bus interfaces if they existed, but for now they use xdg-screensaver
- xdg-screensaver --suspend doesn't currently work on GNOME 3.2 because it uses org.gnome.ScreenSaver.SimulateActivity, which is a no-op[3]

Two solutions I can see:
- standardize org.freedesktop.ScreenSaver, which KDE already uses, and which is very close, if not identical, to org.gnome.ScreenSaver[4]. This is obviously the cleanest solution, as nobody cares about screensavers enough to justify a GNOME-specific API.
- fix xdg-screensaver --suspend. This doesn't seem possible ATM because UnInhibit requires passing the cookie, which xdg-screensaver doesn't give back to the calling application. So making SimulateUserActivity work again would be a workaround, if not a very nice solution. It would be good to have xdg-utils more or less working anyway.

Jon, do you really think the only solution is to impose on third-party projects to use GNOME-specific interfaces? I think the experience with this bug proves this way is a dead-end (and I think they were right to refuse this). Do you agree we need a standard fd.o interface? Would you accept basic patches to make SimulateUserActivity work at least?

Reopening until I get reactions from the clued people around... :-p


1: http://trac.videolan.org/vlc/ticket/4739
2: http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1887
3: http://git.gnome.org/browse/gnome-screensaver/tree/src/gs-listener-dbus.c#n729
4: http://lists.freedesktop.org/archives/xdg/2009-April/010317.html
Comment 32 Ilja Sekler 2012-11-11 13:05:54 UTC
In the discussion starting with <http://lists.mplayerhq.hu/pipermail/mplayer-users/2012-November/085566.html> on MPlayer-users list it turned out to be that the command

dbus-send --session \
          --dest=org.freedesktop.ScreenSaver \
          --type=method_call \
          /org/gnome/ScreenSaver \
          org.freedesktop.ScreenSaver.SimulateUserActivity

which used to work in GNOME 3.4 as a replacement for

gnome-screensaver-command -p

on Fedora 17, doesn't work in GNOME 3.6 on Fedora 18 anymore.

Is it a known issue? Is it intentional? Is the documentation in <http://git.gnome.org/browse/gnome-screensaver/tree/doc/dbus-interface.xml?h=gnome-3-6> obsolete?
Comment 33 nfxjfg 2012-11-11 13:41:28 UTC
(In reply to comment #30)
> Without having looked into mplayer I'd expect this to be doable with ~ two
> dozen lines of code given that it already links against D-Bus.  But assuming
> the developer's decision to be final, this doesn't help either.

mplayer doesn't have any dbus code. dbus is not a direct dependency either. I find it hilarious that you find "~ two dozen lines of code" acceptable, and that even assumes that there's existing dbus code. People do not want to complicate their applications with complicated, bloated dbus usage.

Why doesn't gnome react to XResetScreensaver()? It seems like this is the real bug here.
Comment 34 piruthiviraj natarajan 2012-11-13 18:08:15 UTC
I have the issue on Archlinux gnome 3.6 and fedora 18 as stated by Ilja Sekler. Any solution to this?
Comment 35 Milan Bouchet-Valat 2012-11-29 14:09:09 UTC
Bastien Nocera wrote in bug 689225 a patch to add support for org.freedesktop.ScreenSaver.Inhibit() and .UnInhibit() calls. This means with this patch a single method can be used for GNOME and KDE, and VLC may well use it in the future[1]. Every reasonable app should probably use this instead of --poke, anyway D-Bus is already installed and loaded on all Linux desktops.

1: https://trac.videolan.org/vlc/ticket/7824
Comment 36 Bastien Nocera 2012-11-29 15:40:02 UTC
(In reply to comment #35)
> Bastien Nocera wrote in bug 689225 a patch to add support for
> org.freedesktop.ScreenSaver.Inhibit() and .UnInhibit() calls. This means with
> this patch a single method can be used for GNOME and KDE, and VLC may well use
> it in the future[1]. Every reasonable app should probably use this instead of
> --poke, anyway D-Bus is already installed and loaded on all Linux desktops.

And the MPlayer bug from comment 31 also has a request.

Closing this, as applications should be corrected.
Comment 37 piruthiviraj natarajan 2012-11-29 15:52:40 UTC
Actually I moved to XFCE becoz the gnome-screensaver didn't play nice with mplayer. 
I hope your fix works so that I can work with gnome in future.
Comment 38 Oliver Henshaw 2013-03-08 16:01:50 UTC
(In reply to comment #32)
> In the discussion starting with
> <http://lists.mplayerhq.hu/pipermail/mplayer-users/2012-November/085566.html>
> on MPlayer-users list it turned out to be that the command
> 
> dbus-send --session \
>           --dest=org.freedesktop.ScreenSaver \
>           --type=method_call \
>           /org/gnome/ScreenSaver \
>           org.freedesktop.ScreenSaver.SimulateUserActivity
> 
> which used to work in GNOME 3.4 as a replacement for
> 
> gnome-screensaver-command -p
> 
> on Fedora 17, doesn't work in GNOME 3.6 on Fedora 18 anymore.
> 
> Is it a known issue? Is it intentional? Is the documentation in
> <http://git.gnome.org/browse/gnome-screensaver/tree/doc/dbus-interface.xml?h=gnome-3-6>
> obsolete?

Just for historical interest, this could have been https://bugs.freedesktop.org/show_bug.cgi?id=56649 - which was introduced in xserver-1.13.0 and fixed in xserver-1.13.1 - which explains why it worked on Fedora 17 and was (briefly) broken in Fedora 18.