[mythtv-users] first remote button press is ignored

[Joey Morris]

Stuart Auchterlonie <stuarta at squashedfrog.net> wrote on Tue, Jan 30, 2018 at 02:34:33PM +0000:
> From the data you have provided, we are talking over dbus and
> successfully disabling the screen saver.
> 
> Looking at the code
> https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythui/screensaver-dbus.cpp#L68-L90
> 
> if we get a successful reply from dbus (ie. a non error reply)
> then we set m_inhibited, which ultimately designates if the screen
> is asleep.
> 
> Am i right in inferring that because you don't use dpms / screensaver
> etc, then the screen never actually shuts off?

That's correct.

Looking into this more today, I found that light-locker is what provides the
org.freedesktop.ScreenSaver dbus interface on my system. light-locker is a fork
of gnome-screensaver, but from what I can tell it only locks and unlocks the
screen; it doesn't actually implement a screensaver.


> However the code assumes that because it had a non error response, that
> there is actually a screensaver doing something.
> 
> The only thing i can suggest it pulling apart the dbus reply and
> seeing if it is replying with a non error response, which indicates
> no screen saving has actually been done / or is possible.

I inspected the dbus reply to the Inhibit message, and the only thing returned
is the cookie.


> > So compiling with --disable-qt5dbus is a solution, but is it the right solution?
> > Does other mythfrontend functionality rely on dbus that will be affected by this
> > change? Should I just install a screensaver?
> > 
> 
> I don't think disabling dbus is the right solution, but others
> think it is.
> 
> I would be keen to better understand why we get a non error response.

I added some more logging to trace the logical flow, and I might see what's
going on. First, here's the code that runs right before processing a button
press
(https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythui/mythmainwindow.cpp#L2496-L2498):

    GetMythUI()->ResetScreensaver();
    if (GetMythUI()->GetScreenIsAsleep())
        return;

ResetScreenSaver sends an event that ultimately calls Uninhibit.
GetScreenIsAsleep returns true if the screensaver is inhibited.

(I don't follow the reasoning behind either of these two functions. Why would we
enable the screensaver after receiving a button press? And why would the
screensaver being disabled imply that the screen is asleep? Perhaps I'm
misunderstanding the code.)

I found that the event triggered by ResetScreenSaver was processed only after a
delay, such that it wasn't acted on until after the GetScreenIsAsleep call. My
observation was that the logical flow proceeds as follows:

1. I start playback of a recording.
2. MythTV inhibits the screensaver.
3. I press a button.
4. MythTV calls ResetScreensaver, which sends an event to uninhibit the
   screensaver. The event isn't processed yet, though.
5. GetScreenIsAsleep returns true, because the screensaver is still inhibited.
   Therefore, MythTV returns without processing the button press.
6. The ResetScreensaver event is processed, uninhibiting the screensaver.
7. I press a second button.
8. MythTV calls ResetScreensaver, sending another event to uninhibit the
   screensaver. This doesn't matter now, though, because it's already
   uninhibited.
9. GetScreenIsAsleep returns false, because the screensaver is now uninhibited.
   MythTV continues with this function and processes the button press.

> It would also be interesting to see if the actual current state of
> the sleeping of the screen could be queried via dbus. That would be
> more correct..

d-feet shows a org.freedesktop.Screensaver.GetActive method, which looks
promising. It returns false on my system.