[RFC] Screensaver/blanking inhibition

[Bryce Harrington]

On Thu, Nov 19, 2015 at 07:12:31PM +0000, Daniel Stone 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.
> 
> >>>>>>> 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.

So, in the above scenario, the client would destroy the object when the
movie is paused, and then bind a new inhibit object when play is pressed
again?

Thanks,
Bryce