[mythtv-users] first remote button press is ignored

[Asher Schaffer]

On Sun, Feb 4, 2018 at 7:11 PM Joey Morris <rjmorris.list at zoho.com> wrote:
>
> 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.
>

I know this thread is well over a year old, but I'm seeing the same
behavior, and haven't been able to find a resolution, were you able to
find one?