[RFC] Screensaver/blanking inhibition

[Michal Suchanek]

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