[RFC] Screensaver/blanking inhibition

[Pekka Paalanen]

On Fri, 20 Nov 2015 12:18:29 +0100
Michal Suchanek <hramrach at gmail.com> wrote:

> On 20 November 2015 at 11:39, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 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.
> 
> So long as the object is tied to a surface ther is no need for a ping-pong.

Could you elaborate?


> >> 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")?
> 
> It's for the case when you want something that is not tied to a
> surface and you want the client still have the ability to inhibit
> screensaver yet do not want it to inhibit screensaver indefinitely
> (and then forget to re-enable it).

That's hand-waving. Do you know of a real use case?

For example: showing a remote-controlled desktop in a window; user
input comes directly to the application from the network, and you want
the display server's idle timer to run, but you don't want it to blank
while a user is working with it.

Is that a real use case? I just made that up, but if it's real, it's
concrete.

Btw. even in that case I still believe it must be tied to a surface.
Inhibiting blanking while not showing anything is either useless or a
bad workaround for another problem. IOW, "poke" would take a surface as
an argument and follow the same ignoring rules as the inhibitor object.


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/214f966c/attachment.sig>