[RFC] Screensaver/blanking inhibition

[Bill Spitzak]

On Thu, Nov 19, 2015 at 2:38 AM, Christopher Michael <
cpmichael at osg.samsung.com> wrote:

So, after issuing the inhibit request for a surface, the screensaver
>>>>>> (and screenblanking) will be blocked until the surface is destroyed,
>>>>>> disabled, or otherwise loses visibility or becomes occluded.
>>>>>>
>>>>>
Will it be possible to inhibit the screensaver without putting anything
visible on the screen? I can imagine some programs doing this.

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.

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.


> 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.
>>>>>>
>>>>>
The screensaver object should have several requests. One of them turns the
inhibit on/off.

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.


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

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