[mythtv] DPMS inhibit issues in 0.28

dennis deg at outlook.com
Mon Apr 27 02:01:26 UTC 2015

> FWIW, if anyone is interested in working on a patch, the new code will 
> have to be changed to do a runtime check, something like:
> https://github.com/MythTV/mythtv/commit/dd96b80f#diff-e68a289d9e5d8b92bd9d39461cf38ea2 
> but the challenge is properly detecting whether DBus control will 
> actually work.  Unfortunately, the only "required" DBus methods in the 
> Freedesktop specification are Inhibit and Uninhibit ( 
> http://people.freedesktop.org/~hadess/idle-inhibition-spec/re01.html) 
> and there are none to say whether a DBus-enabled screensaver is 
> actually running (and, if nothing else GNOME3/gnome-shell screen saver 
> implements only the required methods, so we can't assume others will 
> be there).
> Therefore, my recommendation would be to move the DPMS-support out of 
> screensaver-x11.cpp and into a ScreenSaverDPMS helper class (which has 
> the code to detect whether DPMS is enabled, as well as DisableDPMS and 
> RestoreDPMS), then move the code that checks whether xscreensaver is 
> active:
> https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythui/screensaver-x11.cpp#L40 
> into a static function in ScreenSaverX11.  Then, change ScreenSaverX11 
> /and/ ScreenSaverDBus to make calls to ScreenSaverDPMS in addition to 
> their xscreensaver/DBus activities and the detection code would be 
> something like:
> #if defined(USING_X11)
> #if defined(USING_DBUS)
>     if (ScreenSaverX11::IsXScreenSaverRunning())
> #endif    // USING_DBUS
>         ScreenSaverSingleton = new ScreenSaverX11();
> #if defined(USING_DBUS)
>     else
>         ScreenSaverSingleton = new ScreenSaverDBus();
> #endif    // USING_DBUS
> where the above assumes that DBus screensaver control is only valid on 
> X11-based systems, which I think is correct(?).
> This way, if xscreensaver is running (which is the only way the 
> xscreensaver control will work), we use its control mechanism (since 
> it does not and will not support DBus).  Otherwise, we use DBus 
> control.  Since we can't know if DBus control will work, DBus control 
> has to be the fallback.  And, we still make DPMS calls (if DPMS is 
> enabled on the server) whether we use xscreensaver or DBus to control 
> the actual screensaver.  However, if MythTV is compiled without DBus 
> support, we will just use the xscreensaver control (which will still 
> make DPMS calls).
> Mike

 From what I can tell,  currently upon starting of the frontend,  it is 
checking 4 different methods to see if it can connect via dbus. 
Whichever it finds,  it trys to use when actually trys to inhibit the 
screeensaver.   Is this correct?

2015-04-26 20:23:51.284136 I  ScreenSaverDBus: Created for DBus service: 
2015-04-26 20:23:51.285120 E  ScreenSaverDBus: Could not connect to 
dbus: The name org.freedesktop.PowerManagement.Inhibit was not provided 
by any .service files
2015-04-26 20:23:51.285928 E  ScreenSaverDBus: Could not connect to 
dbus: The name org.mate.SessionManager was not provided by any .service 
2015-04-26 20:23:51.287686 I  ScreenSaverDBus: Created for DBus service: 

In my case,  it looks like it is finding 2 methods that appear valid.   
However,  when it actually goes to inhibit the screensaver it looks like 
that one is actually working.

*2015-04-26 20:29:28.756780 I  ScreenSaverDBus: Successfully inhibited 
screensaver via org.freedesktop.ScreenSaver. cookie 764684952. nom nom*
2015-04-26 20:29:28.757035 E  ScreenSaverDBus: Failed to disable 
screensaver: Method "Inhibit" with signature "ss" on interface 
"org.gnome.SessionManager" doesn't exist

This is on ubuntu 14.04 where I am not using any screen saver,  but just 
issuing "xset dpms 0 0 600" on startup.   So with what your proposing,  
you would still inhibit DPMS even if it thinks it succeeded by other 
methods such as dbus ( if complied with both USING_X11 & USING_DBUS)?   
Kind of a shotgun approach?   Looks like it would work for me..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20150426/352f5041/attachment.html>

More information about the mythtv-dev mailing list