[RFC] Screensaver/blanking inhibition

[Bill Spitzak]

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.

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.

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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151123/cebf48a7/attachment.html>