Confirming same behaviour.

Also same bugreport in debian http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg681088.html

Not surprising as that function has been replaced with a FIXME ;)

Created attachment 145050 [details] [review]
Patch to apply to gs-monitor.c

Hmm, do not know why, but patch not working when mplayer is running.

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)

(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? :)

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.

For mplayer i use heartbeat-cmd.
Just put:
heartbeat-cmd="gnome-screensaver-command -p"
in ~/.mplayer/config and mplayer call poke every 30 second.

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

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.

Why does the status of this remain unconfirmed?

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);


}

Importance->High, regression.

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.

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.

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.

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?

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.

Could gnome-screensaver devs explain the way to go?
1. Reintroduce poke
2. Ask mplayer and co. people to fix their apps

Thanks

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. :)

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

*** Bug 639680 has been marked as a duplicate of this bug. ***

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.

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.

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

(In reply to comment #26)

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

Nod.

Two times WONTFIX means stagnation for the time being.

Not so ugly work around is to use caffeine: https://launchpad.net/caffeine

(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.

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 ;-)

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

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?

(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.

I have the issue on Archlinux gnome 3.6 and fedora 18 as stated by Ilja Sekler. Any solution to this?

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

(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.

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.

(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.