[RFC] Screensaver/blanking inhibition

[Pekka Paalanen]

On Thu, 19 Nov 2015 22:46:06 +0100
Michal Suchanek <hramrach at gmail.com> wrote:

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

Yes, it is tied to the surface. The create method on the global
interface can have the surface as an argument. This is a common pattern
in Wayland extensions.

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

We don't want yet another ping/pong protocol in this one. We can leave
it as a shell detail to determine whether a client is locked up and how
to respond to that. I do not think it is really necessary to spec that
in the protocol.

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

What use cases are there for the idle timer reset ("poke")?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151120/8d2ce4a0/attachment.sig>