Problems with Screensavers and other activity sensitive demons.

[Carsten Haitzler (The Rasterman)]

On Thu, 7 Jun 2007 09:10:23 +0200 Lubos Lunak <l.lunak at suse.cz> babbled:

> On Thursday 07 of June 2007, Carsten Haitzler wrote:
> > On Thu, 07 Jun 2007 02:02:01 +1000 Graeme Gill <graeme2 at argyllcms.com>
> > babbled:
> >
> > XScreenSaverSuspend(). it's there. it's engineered. it's documented. the
> > problem lies  not in lack of engineering in the X11 department. its a very
> > clean implementation and exactly what you need. if screensaver apps are
> > hacking around the xscreensaver extension and not using
> > XScreenSaverSelectInput() + XScreenSaverNotifyEvent's - then they need to
> > be corrected ad they simply are not playing nice (tm).
> 
>  Actually, to my best knowledge, none of this is true, except for "it's
> there" and "it's documented". It's over-engineered, it's unmaintained and as
> a consequence it's broken. You can have a look at 
> http://bugs.freedesktop.org/show_bug.cgi?id=1419 for why the XScreenSaver 
> maintainer thinks it's broken, and if that's not enough I can dig in the KDE 
> screensaver for more. Screensaver apps are hacking around the extension or 
> just plain ignoring it because they have to.

if you don't have the extension - fair enough. hack. i know jamie WANTS just an
idle event - but xscreensaver provides AN event when the "screensaver" kicks in
(i.e. idleness for the xscreensaver timeout has been reached). this is
sufficient (and necessary) for what it needed of xscreensaver (in the old
fashioned pre xrandr 1.2 world). jamie chooses NOT to use it. i happen to use
that interface and event - and it works. i see no GOOD reason for xscreensaver
not to use it. the api and mechanism to do what graeme wanted is there without
having to exec 23 things, use 3 dbus interfaces etc. etc. just to try and
inhibit "screensaver of the month" from kicking in. i haven't tried the
XScreenSaverSuspend() call yes - but i assume it works, if it doesn't that's a
bug to be fixed (and works within the screensaver word - not works with hacks
around xscreensaver like monitoring all events on all windows to hack around
xscreensaver extension not existing).

why do we nee4d dbus and "exec this" interfaces - and multiple ones. when a
perfectly good one ALREADY EXISTS? :)

> > > To avoid this I went to the trouble in my application
> > > of temporarily disabling the screensaver while it is running,
> > > using the documented mechanism under X11 for doing this:
> > > XSetScreenSaver(). It didn't take long to discover that
> > > this in fact was ineffective on the Red Had clone system
> > > I was testing on. Some investigation revealed that 
> > > the screensaver favoured by that distribution (xscreensaver)
> > > wasn't playing nice with X11, and in fact was ignoring
> > > the X11 screensaver mechanism. Perusal of the authors
> > > website indicated that he had no interest in fixing this
> > > problem, but merely suggested that application such
> > > as mine run the "xscreensaver-command -deactivate"
> > > periodically. Since there seem no other easy to implement
> > > way of disabling xscreensaver, added a fork() then execlp()
> > > every 60 seconds to do this. Ugly but it worked.
> > >
> > > Recently I have had a report from a user indicating that
> > > a screensaver had interrupted calibration of his display.
> > > Enquiry revealed that it was a new screensaver, the
> > > GnomeScreensaver. Perusal of it's web site indicated
> > > that once again, it is not backwards compatible with
> > > the X11 screensaver mechanism, and that it uses yet another
> > > method of control, this time based on D-Bus. While this seems a
> > > little better choice than the xscreensaver approach, the lack
> > > of backwards compatibility is distressing, and the means of
> > > signalling activity so that it doesn't trigger bodes poorly
> > > for future compatibility. It apparently needs a
> > > "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!)
> > >
> > > This looks bad, as it seems certain that when someone develops
> > > a KDE screensaver
> 
>  We already do have one :) , in fact we've had it for like 8 years at least. 
> And it should suspend when either DPMS or the XScreensaver extension are 
> suspended, so it's presumably missing from your list because nobody had to 
> complain about it.
> 
> > > , org.kde.screensaver will need signalling, 
> > > and when fred develops a new screensaver, com.fred.screensaver will
> > > need signalling etc. And what about power monitoring demons ? Will
> > > they each need to be named and known, and a long list added to
> > > as people add new ones to the operating systems, each time triggering
> > > a flood of support calls for applications such as mine ?
> > >
> > > There doesn't seem like there's much system level design going
> > > on here, just each application having to look after itself.
> 
>  As already said in another answer, your best choice at this moment should be 
> xdg-screensaver from xdg-utils.
> 
> -- 
> Lubos Lunak
> KDE developer
> --------------------------------------------------------------
> SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
> Lihovarska 1060/12   tel: +420 284 028 972
> 190 00 Prague 9      fax: +420 284 028 951
> Czech Republic       http//www.suse.cz
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)