[RFC] Screensaver/blanking inhibition

[Michal Suchanek]

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.

Also the protocol should probably cover the cases when a client locks up.

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.

>>>> Makes sense ("potentially" could inhibit other things depending on scope
>>>> and how it grows)
>>
>> Absolutely it should by default inhibit any kind of notifier or any other
>> changes to the display not triggered by the user (it also should NOT inhibit
>> changes that the user triggers, such as hitting a shortcut key that creates
>> a popup).
>>
>> Among these changes that must be inhibited are "things that have not been
>> invented yet but may appear in a future desktop". Therefore a per-thing api
>> to inhibit them is not going to work and this must inhibit them all.
>>
>> The api can be enhanced in the future if you want finer control over what is
>> inhibited.
>
> No. People want to receive notifications whilst they watch movies.

At least some people sometimes, yes.

Thanks

Michal