[RFC] Screensaver/blanking inhibition

[Daniel Stone]

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.

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

> The screensaver object should have several requests. One of them turns the
> inhibit on/off.

The screensaver object and the inhibition object are not the same thing.

>>>> Yes I think it makes sense to add this to its own extension. A
>>>> "wp_inhibiter" in a inhibiter XML file that inhibit things.
>
>
> Please don't use any name that does not have the word "screensaver" in it,
> because that is the word programmers are going to look for. My suggestion is
> "wpz_screensaver_v1" (or whatever the rules for experimental protocols are).
> I suspect this api will quickly get enhanced with other api (such as events
> when the screensaver turns on/off), so I would not use the word "inhibit" at
> all.

It's not a screensaver API, it's a screensaver/blanking inhibition
API. Everyone else already uses 'inhibit'.

I don't see the point in adding events until we desperately need them.
What happens if you only blank one screen but leave the others on? And
so on.

>>> 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.
Presentation is something else altogether.

>>>> Not so sure about the scope though. If its not about surfaces on outputs
>>>> or input devices or focus or display protocol things it should just be a
>>>> D-Bus protocol.
>
> No please don't! It has to inhibit everything by default that you would
> think that a program trying to disable the screensaver is also trying to
> disable. It does not matter where or how they are implemented.

No, it doesn't.

Cheers,
Daniel