[mythtv] Request - disable screensaver

[Joseph A. Caputo]

On Monday 17 November 2003 20:27, Cliff Draper wrote:
> I'm digging up an old thread, 'cause I finally got a few cycles to
> look into it.
>
> From: "Joseph A. Caputo" <jcaputo1 at comcast.net>
> Date: Fri, 17 Oct 2003 15:48:08 +0000
>
> > On Friday 17 October 2003 07:17 pm, Cliff Draper wrote:
> > > From: "Joseph A. Caputo" <jcaputo1 at comcast.net>
> > > Date: Fri, 17 Oct 2003 14:41:14 +0000
> > >
> > > > I'm not sure it's as simple as that... while it will enable the
> >
> > screensaver, I
> >
> > > > think there might still be a problem.  In my experience before
> > > > I disabled
> >
> > the
> >
> > > > screensaver, if the screensaver kicked in while I was watching
> > > > something, taking actions with my LIRC remote didn't clear the
> > > > screensaver; I needed
> >
> > to
> >
> > > > plug in a real keyboard or mouse to get it to clear.  I think
> > > > this is
> >
> > because
> >
> > > > the LIRC device is not recognized as an X input device; it
> > > > merely runs through a client program that fires off X-events. 
> > > > So, yes, you could turn
> >
> > on
> >
> > > > the screensaver when in 'menu' mode, but if your only input is
> > > > a remote control you won't be able to clear the screensaver.
> > >
> > > Yes, I think you're right here.  Well, I see 2 ways to save the
> > > `xset s on` idea: figure out how to make LIRC better emulate a
> > > keyboard, or call `xset s reset` for every keypress that myth
> > > gets.  I think the latter would work, but the former would be
> > > more elegant.
> >
> > Well, LIRC can't emulate a real X-input keyboard device (well, not
> > without rewriting LIRC), but it *can* emulate an X-input mouse
> > device, so that would be one way to go.
> >
> > > > The real solution is to build screensaver calls directly into
> > > > Myth.
> >
> > Shouldn't
> >
> > > > be that hard.
> > >
> > > What do you mean by direct screensaver calls?
> >
> > I mean code that uses the Xlib calls directly:
> > XSetScreenSaver, XForceScreenSaver, XActivateScreenSaver,
> > XResetScreenSaver, XGetScreenSaver
> >
> > AFAIK, Ogle uses these to enable/disable the screensaver when
> > playing a DVD. Ideally, Myth would:
> >
> > 	- Disable the screensaver whenever playing video/unpaused
> > 	- Enable the screensaver if the video is paused
> > 	- Enable the screensaver if Myth is showing a GUI screen (i.e.,
> > not playing video
> > 	- Reset the screensaver (i.e., leave it enabled but un-blank the
> > screen) whenever user input is detected.
>
> So on my home machine, I've added some functions for disabling the
> screensaver, restoring the screensaver, and reseting the timer.  When
> the TV player's state transitions to playing video, I disable the
> screensaver.  When the state transitions to not playing video, I
> restore the screensaver.  And whenever a key is pressed, the timer
> gets reset.
>
> This all works fine except for 2 big issues.
>   1. Key presses in MythTV do not all flow thru the same location.
>   This class inherents from that class and overrides it's key press
>   handler.  So far, I've editted 16 .cpp files to call the reset
>   screensaver function (haven't touched any of the plugins yet).  If
>   only there were 1 spot that all keys went thru before being sent
> off to the proper handler....  The delegator pattern might work well
> here.  And this would probably help any idea of having remappable
> keybindings.  Is there a simpler and more maintainable way of doing
> this?  (Change LIRC?)


Couldn't you install a global event filter on keypress events?  I 
*think* you may be able to install an event filter on the QApplication 
object that would catch all QKeyEvent events, reset the timer, then 
pass the event along to whomever is supposed to get it (dialog, widget, 
whatever).  It's been a while since I've looked into how this mechanism 
works, but it was an approach I'd been considering when I thought I was 
going to work on a new user-action/keybinding architecture.


>   2. Screensavers are not consistent in X.  I'm a little disappointed
>   with this, as there are 3 separate protocols.  There's the basic
>   blanker done with XActivateScreenSaver (`xset s on`).  There's the
>   DPMS calls which try to change the power state of the monitor
> (`xset +dpms`).  And finally, there's the xscreensaver daemon (the
> one with all of the pretty screensavers) which does not have an
> official C API for talking to it.  My changes deal well with the
> first two, but xscreensaver is questionable.  First, while it would
> be very cool to see real screensavers (toasters flying, etc), do you
> want this on a machine doing real time audio/video encoding where
> you're trying to squeeze every last cycle out of your machine?  It
> would probably be fine on a dedicated frontend.  Second, the way you
> reset the timer on xscreensaver is ugly.  See
>   http://www.jwz.org/xscreensaver/faq.html#dvd   Basically to disable
>   the screensaver, you're suppose to fork a process every minute and
>   run the xscreensaver-command to reset the timer.  Any ideas on a
>   good way to deal with this?

I wouldn't bother with xscreensaver -- there's really no need to be 
running it, and many desktop environments don't use it anyway.  KDE has 
its own mechanism, and I presume Gnome has its own, too.  I would just 
stick to the screen blanking & DPMS X mechanisms for now.  I think most 
folks with dedicated frontends are running a lightweight window manager 
with no screensaver daemon, anyway.

-JAC