[RFC] Screensaver/blanking inhibition

[Michal Suchanek]

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.

>
>> 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).

Thanks

Michal