[mythtv-users] viewer falls asleep with the EPG open - plasma burn in concerns

[Michael T. Dean]

On 03/29/2010 03:13 PM, Johnny Walker wrote:
> On Mon, Mar 29, 2010 at 1:32 PM, Michael T. Dean wrote:
>    
>> On 03/29/2010 10:45 AM, Johnny Walker wrote:
>>      
>>> On Tue, Mar 23, 2010 at 7:15 PM, Johnny Walker wrote:
>>>        
>>>> On Thu, Mar 11, 2010 at 9:01 PM, Daniel Kristjansson wrote:
>>>>          
>>>>> On Thu, 2010-03-11 at 19:30 -0600, Johnny Walker wrote:
>>>>>            
>>>>>> So the only way I can think to protect my Plasma from EPG burn-in
>>>>>> (aside from never falling asleep) would be to re-enable it when the
>>>>>> EPG is loaded on the screen, even if I'm still in LIVETV mode.
>>>>>>
>>>>>> Does this sound correct?
>>>>>>              
>>>>> Yes, sounds reasonable.
>>>>>
>>>>> In working on this I found the following in the code
>>>>>            
>>>> libmythui/screensaver-x11.cpp:
>>>>
>>>> if (m_timeoutInterval == -1)
>>>>          {
>>>>              m_timeoutInterval = GetMythDB()->GetNumSettingOnHost(
>>>>                  "xscreensaverInterval", GetMythDB()->GetHostName(), 50) *
>>>> 1000;
>>>>          }
>>>>
>>>>          if (m_timeoutInterval>    0)
>>>>              StartTimer();
>>>>
>>>> I don't seem to have 'xscreensaverInterval' in my settings table.
>>>>
>>>> I grepped my working copy of .22 and I don't see it mentioned anywhere
>>>> else.
>>>>
>>>> The reason I'm asking is - I've put 'xset s 60 60' in my .xsessionrc file
>>>> and somehow it's getting changed to 0 which is making my screensaver not
>>>> happen when I'm paused.
>>>>
>>>> I added a call to EnableScreensaver to the NuppelVideoPlayer::Pause
>>>> method
>>>> but since 'xset q' shows it's back at 0 it does me no good. When I
>>>> manually
>>>> 'xset s 60 60' again however, it starts working as expected.
>>>>
>>>> Do any of you know what gives
>>>>          
>>> Ok - I've grepped through the code for .22 lookiung for 'xset' and I don't
>>> see where the code would be disabling the screen saver.
>>>        
>> MythTV never does anything with xset.  It only tests to see if xscreensaver
>> or gnome-screensaver is running.  If so, it will "poke" the screensaver once
>> every 50sec (the default value of the hidden xscreensaverInterval setting
>> you mentioned above) to prevent the screensaver from activating during
>> playback.
>>
>> Note, however, that many screensaver programs will enable/disable things
>> like DPMS.
>>      
>>> When I'm in Media Library -->    Watch Videos - and a video ends and returns
>>> me
>>> to that screen, the display just sits there, waiting to burn in on my
>>> Plasma
>>> television.
>>>
>>> If I ssh in to the frontend and run 'xset s 60 60' it starts working and
>>> protecting my screen.
>>>
>>> I'm really concerned about this - it seems like an odd oversight in the
>>> functionality. Am I the only one having this issue?
>>>        
>> Any reason you're not running one of the supported screensaver programs?
>>      
> Where are those listed?

Only supported ones are xscreensaver and gnome-screensaver, as shown in 
mythtv/libs/libmythui/screensaver-x11.cpp .

>   I used the xfrce settings manager to enable
> that adorable little ant with a flashlight nose screensaver and it
> never appears when mythfrontend is running. When I said previously
> that I can enter 'xset s 60 60' and it works as expected, I kinda
> lied. The screen dims but Rudolph the Flashlight Ant never appears.
>    
>> I have a plan (very low on my TODO list--especially since I don't use
>> screensavers on MythTV) to add xdg-screensaver (
>> http://portland.freedesktop.org/xdg-utils-1.0beta3/xdg-screensaver.html )
>> support to MythTV (see http://portland.freedesktop.org/wiki/ ).  By default,
>> MythTV would use xdg-screensaver, if available.  If not, it would fall back
>> to the current xscreensaver/gnome-screensaver support.
>>
>> Since xdg-screensaver works on a completely different principle from
>> xscreensaver/gnome-screensaver, we can't just stick xdg-screensaver in place
>> of the xscreensaver/gnome-screensaver commands in the current code.  The
>> current code never deactivates (or activates) the screensaver program, but
>> just sends it messages periodically that it should not activate.  This way,
>> if mythfrontend crashes, it doesn't leave the screensaver deactivated.
>>
>> xdg-screensaver, on the other hand, uses a suspend/resume approach.
>>   mythfrontend would ask xdg-screensaver to suspend the screensaver and
>> provide a mythfrontend window ID.  Then, when the screensaver should resume,
>> mythfrontend would tell xdg-screensaver.  If mythfrontend crashes,
>> xdg-screensaver would notice the window with the given ID disappearing and
>> would let the screensaver resume normal operations.
>>
>> If you'd like to work on this, I'd love to be able to mark it off my TODO
>> list.  :)
>>      
> I would /LOVE/ to work on this.  Is there already a trac ticket? (I
> suppose I could go look)
>
>    

No ticket, yet.  No code, yet, either (so no need for a ticket).  Just 
an idea way down low on my TODO list.  But, since xdg-screensaver should 
work with all screensaver programs, it should solve problems for anyone 
using any screensaver that's not xscreensaver and not gnome-screensaver.

You'll likely want to create a new class, ScreenSaverXDG (in a new file, 
mythtv/libs/libmythui/screensaver-xdg.cpp ), and in 
mythtv/libs/libmythui/screensaver.cpp change the #if defined(USING_X11) 
to first check if xdg-screensaver is installed/available (maybe with a 
static function in ScreenSaverXDG) and if so, use ScreenSaverXDG, or if 
not, fall back to ScreenSaverX11.

The new class should be significantly simpler than ScreenSaverX11 since 
ScreenSaverX11 basically implements the same functionality already 
provided by xdg-screensaver.

>> And, as you and Daniel are aware, the current code doesn't really handle
>> transitions from "suspend" to "resume" very well.  We keep poking the
>> screensaver when the EPG is displayed, and there may be other parts of Myth
>> where we should disable the screensaver and we don't.  So, even just fixing
>> these up would be nice.
>>      
> I've been drawing the same conclusions and am glad to hear you confirm
> it. I was worried I had something munged up on my system.
>    

And we'd love some patches for it.  ;)

Mike