Dnia 21-12-2007, Pt o godzinie 10:25 +0100, Adam Tlałka pisze:
Dnia 21-12-2007, Pt o godzinie 10:00 +0100, Reimar Döffinger pisze:
Hello, On Fri, Dec 21, 2007 at 08:00:49AM +0100, Adam Tlałka wrote: [...]
So while using XScreenSaverSuspend according to a) screensaver could be forcibly activated by other app and as stated in b) XScreenSaverSuspend call will not deactivate already active screen saving mode - so if you start mplayer from some script there will be no screen saver deactivation.
XScreenSaverSuspend actually seems like the much more sensible behaviour to me, why should we e.g. disallow explicit locking of the screen via the screensaver application just because MPlayer is running?
Why? Because if mplayer is running it means to me that we want to see what is played. If we want to turn on the screensaver we can always pause or stop playing and then switch on the screensaver if we want to activate it at once or it will be activated automatically after defined timeout. If using XScreenSaverSuspend call you can start mplayer from remote script and then you have to generate some mouse or keyboard events in case of previously activated screen save mode to deactivate it. So if you want to remotely control mplayer (not from DPY on which you play) XScreenSaverSuspend will not always be good enough to activate switching the display to on without user intervention.
Additionally if do not want to use the heartbeat function you can use XScreenSaverSuspend(dpy, True) call and then XResetScreenSaver(dpy) once to be sure that previously activated mode will be disabled. If you remotely control the mplayer program you should do these two calls before starting playing and call XScreenSaverSuspend(dpy, False) in case of pause/stop/end of playing. Regards -- Adam Tlałka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group - - - ~~~~~~ Computer Center, Gdańsk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl