[RFC] Screensaver/blanking inhibition

[Bill Spitzak]

On Thu, Nov 19, 2015 at 11:12 AM, 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.
>

Yes I believe that will work, but will it be possible to inhibit the
screensaver without putting anything visible on the screen?

Probably not a big deal, actually. The only application I can really think
of for this is to force presentation of some other application that does
not use the inhibit api, and such a tool may still map some kind of
(normally invisible) overlay for popup controls, so the inhibit could be
tied to that.



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

Ok I think I see where you are going. I would still have the word
"screensaver" in the name, ie "screensaver_inhibit". Though of course it is
going to inhibit other things, but I'm afraid the fact that people
searching for this api are going to look for the word "screensaver" about
100 times more often than they look for the word "inhibit" means it had
better be in the name. Thus zwp_screensaver_inhibit_v1 is probably the name.

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

I may have been too specific about what is disabled. Let me try to be more
careful:

There are two sets.

A = "things that a user watching a movie does not want to happen".

B = "things that exist in future wayland desktop environments but have not
been invented yet and thus there is no api for".

I propose the following:

1. The intersection of these two sets is not empty.

2. It is desirable for the inhibit api to be capable of disabling
everything in set A.

3. It is a lot easier to describe the set A than to describe this
intersection, since the second description requires a date that determines
the contents of set B (it reduces over time as things are invented).

Therefore there should be a way to inhibit all of A with a single api.

I propose that this be the default initial state of inhibit. As this
contains everything, all remaining controls can be done by removing
different subsets of A from the inhibit. New subsets can be added or new
things added to existing subsets as they are invented, without breaking any
clients expectations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151119/ea290878/attachment.html>