[RFC] Screensaver/blanking inhibition

[Bryce Harrington]

On Mon, Nov 23, 2015 at 11:51:07AM -0800, Bill Spitzak wrote:
> I now agree that tying the inhibit to a surface is exactly the right thing
> to do.
> 
> Besides preventing blanking of only the correct output, this could also
> allow the compositor to show popup notifications when the compositor knows
> they will not interfere with the surface.

Not sure what you mean here - mind elaborating?

> I also think there is no need for the "all outputs inhibit". That is just
> an artifact of how current systems work. I know for a fact that I am
> annoyed that watching a movie on the tv screen disables the screen saver
> and thus leaves the desktop monitor on (and projecting a glow against a
> wall behind the tv) and I physically have to turn that monitor off to fix
> this. I would guess that disabling the screen saver only on the monitors
> being used is the desired behavior by everybody, and thus should be the
> supported. The only reason to blank all of them is technical impossibility
> of blanking only one of them.

Hmm, you may be right.  Certainly is an interesting direction to take.

I'm trying to think of a use case where you have, say, a dual head
configuration, and are watching something on one monitor but providing
no input for an extended period of time, and where the second (unused)
monitor should *not* powersave normally.  I can't think of anything
fitting that situation, but my gut suggests people are going to want it.
Indeed, as you say, most of the cases I can think of are ones where it
might be disconcerting at first but it *is* what you want technically.

I suppose this is something that's easier to omit and add later when a
need proves itself, than to include it from the start and try to remove
it later.  So I can leave that bit out until someone presents a viable
use case where it's needed.
 
> So it should only inhibit disabling the outputs the attached surface is
> viewed on.
> 
> Also my concern about requiring a visible output is I think not a problem
> for any real application I think.

Thanks for the reviews!
Bryce

> On Fri, Nov 20, 2015 at 6:10 AM, Michal Suchanek <hramrach at gmail.com> wrote:
> 
> > On 20 November 2015 at 14:43, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > On Fri, 20 Nov 2015 14:10:47 +0100
> > > Michal Suchanek <hramrach at gmail.com> wrote:
> > >
> > >> On 20 November 2015 at 12:48, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > >> > On Fri, 20 Nov 2015 12:18:29 +0100
> > >> > Michal Suchanek <hramrach at gmail.com> wrote:
> > >> >
> > >> >> On 20 November 2015 at 11:39, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > >> >> > On Thu, 19 Nov 2015 22:46:06 +0100
> > >> >> > Michal Suchanek <hramrach at gmail.com> wrote:
> > >> >> >
> > >> >> >> On 19 November 2015 at 20:12, Daniel Stone <daniel at fooishbar.org>
> > wrote:
> > >> >> >> > Hi,
> > >> >> >> >
> > >> >> >> > On 19 November 2015 at 19:05, Bill Spitzak <spitzak at gmail.com>
> > wrote:
> > >> >> >> >> I feel like there is no need to tie it to a surface. In
> > Wayland the client
> > >> >> >> >> is always notified of any changes to it's state, so it can
> > update the
> > >> >> >> >> screensaver object to match. (destruction of the screensaver
> > object would of
> > >> >> >> >> course remove the inhibit).
> > >> >> >> >>
> > >> >> >> >> The surface may be necessary to indicate if only one output is
> > to have the
> > >> >> >> >> screensaver inhibited, but I think wayland clients are aware
> > of which output
> > >> >> >> >> their surfaces are on so instead the output could be indicated
> > directly.
> > >> >> >> >
> > >> >> >> > By default it should be tied to a surface.
> > >> >> >>
> > >> >> >> That sounds quite reasonable. The compositor can point to a
> > particular
> > >> >> >> surface that inhibits screen blanking, the surface can be removed
> > >> >> >> one-sidedly by the compositor, the compositor may choose to cease
> > the
> > >> >> >> blank-inhibit function when the surface is obscured/unmapped/..
> > >> >> >>
> > >> >> >> >
> > >> >> >> >>>>>>>> In X11, various getter functions are provided for the
> > application to
> > >> >> >> >>>>>>>> poll inhibition status.  For Wayland, instead of
> > getters, the current
> > >> >> >> >>>>>>>> state is just be pushed to the client when the inhibitor
> > global is
> > >> >> >> >>>>>>>> bound, and then updates pushed if/when the status
> > changes.
> > >> >> >> >>>>>>>>
> > >> >> >> >>>>>>>
> > >> >> >> >>>>>>> This makes sense, and follows "standard" wayland practice
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> I don't see any reason for a client to know about any other
> > clients
> > >> >> >> >> inhibiting the screensaver, and this might be a security leak
> > too.
> > >> >> >> >
> > >> >> >> > Yes, seems a bit pointless.
> > >> >> >> >
> > >> >> >> >>>>>>>> A corresponding uninhibit API will be added as well.
> > For example, a
> > >> >> >> >>>>>>>> movie player may wish to inhibit while a video is
> > playing but
> > >> >> >> >>>>>>>> uninhibit
> > >> >> >> >>>>>>>> when it is paused.
> > >> >> >> >
> > >> >> >> > Just make the inhibit request return a new object, which upon
> > destroy,
> > >> >> >> > removes the inhibition. That way you don't even have duplicate
> > >> >> >> > codepaths for client exiting uncleanly vs. client removed
> > inhibition.
> > >> >> >>
> > >> >> >> Except then it is not bound to a surface anymore.
> > >> >> >
> > >> >> > Yes, it is tied to the surface. The create method on the global
> > >> >> > interface can have the surface as an argument. This is a common
> > pattern
> > >> >> > in Wayland extensions.
> > >> >> >
> > >> >> >> Also the protocol should probably cover the cases when a client
> > locks up.
> > >> >> >
> > >> >> > We don't want yet another ping/pong protocol in this one. We can
> > leave
> > >> >> > it as a shell detail to determine whether a client is locked up
> > and how
> > >> >> > to respond to that. I do not think it is really necessary to spec
> > that
> > >> >> > in the protocol.
> > >> >>
> > >> >> So long as the object is tied to a surface ther is no need for a
> > ping-pong.
> > >> >
> > >> > Could you elaborate?
> > >>
> > >> This is pretty much a usability point of view. When I have a (paused)
> > >> media player on a virtual X desktop that is not shown it still
> > >> inhibits the screensaver (through some message call that does not
> > >> actually quite point to a particular X11 client).
> > >>
> > >> When this is tied to a surface the compositor can decide by its policy
> > >> if it's relevant or not. Such as not taking into account surfaces that
> > >> are not shown.
> > >>
> > >> If/when this becomes a problem it can also have an indicator somewhere
> > >> which shows that the screensaver is inhibited and expands to a list of
> > >> surfaces that inhibit it on click or whatever.
> > >
> > > Yes, all that makes sense, but how does it relate to the app freezing?
> > > I thought "client locks up" referred to the client freezing, as in,
> > > becoming unresponsive. My misunderstanding?
> >
> > It relates to usability quite clearly. When client 'locks up' the
> > surface remains but the client is no longer showing whatever it was
> > supposed to show for which the screen was supposed not to blank. Now
> > since the request is tied to a surface the compositor can decide
> > automagically or the user by hand that the client is not performing
> > and either revoke the request or remove the surface entirely.
> >
> > In X11 land the inhibit request is delivered through some backyard
> > protocol that does not tie the request to a particular window so there
> > is no way to decide that the request can be revoked. When an
> > application requests that the screensaver be inhibited it may stay
> > inhibited (and actually actively unblank when blanked) indefinitely
> > for no apparent reason. If the protocol includes death notification
> > such as dbus you can end the request by killing the application but
> > you would have to know which application requested the screen blank
> > inhibition.
> >
> > >
> > >
> > >> >> >> Xscreensaver has an inhibit protocol which just allows the
> > application
> > >> >> >> reset the idle timer as if the user pressed a key. That's not
> > ideal
> > >> >> >> but when combined with the possibility to register (and
> > unregister) a
> > >> >> >> surface as blank-inhibiting when visible this would probably cover
> > >> >> >> most without much effort on the application side.
> > >> >> >
> > >> >> > What use cases are there for the idle timer reset ("poke")?
> > >> >>
> > >> >> It's for the case when you want something that is not tied to a
> > >> >> surface and you want the client still have the ability to inhibit
> > >> >> screensaver yet do not want it to inhibit screensaver indefinitely
> > >> >> (and then forget to re-enable it).
> > >> >
> > >> > That's hand-waving. Do you know of a real use case?
> > >> >
> > >> > For example: showing a remote-controlled desktop in a window; user
> > >> > input comes directly to the application from the network, and you want
> > >> > the display server's idle timer to run, but you don't want it to blank
> > >> > while a user is working with it.
> > >> >
> > >> > Is that a real use case? I just made that up, but if it's real, it's
> > >> > concrete.
> > >> >
> > >> > Btw. even in that case I still believe it must be tied to a surface.
> > >> > Inhibiting blanking while not showing anything is either useless or a
> > >> > bad workaround for another problem. IOW, "poke" would take a surface
> > as
> > >> > an argument and follow the same ignoring rules as the inhibitor
> > object.
> > >> >
> > >>
> > >> This is usually the case with remote desktop access applications. They
> > >> do not show anything, move the cursor without the user touching any
> > >> actual input device, and inject keypresses without the user actually
> > >> touching any input device buttons. There are also those
> > >> multi-computing applications that do not actually capture the screen
> > >> content but allow single input device to control multiple computers
> > >> using physically adjacent screens.
> > >
> > > That is not what I was describing. You describe how an arbitrary
> > > process takes control of the compositor by feeding it fake input. I am
> > > talking about a normal application, that happens to show a window
> > > showing a desktop of somewhere else.
> >
> > That's basically not different from a media player. You just have a
> > different kind of movie.
> >
> > Thanks
> >
> > Michal
> >