[RFC] Screensaver/blanking inhibition

[Pekka Paalanen]

On Fri, 20 Nov 2015 14:10:47 +0100
Michal Suchanek <hramrach at gmail.com> wrote:

> On 20 November 2015 at 12:48, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 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?
> 
> This is pretty much a usability point of view. When I have a (paused)
> media player on a virtual X desktop that is not shown it still
> inhibits the screensaver (through some message call that does not
> actually quite point to a particular X11 client).
> 
> When this is tied to a surface the compositor can decide by its policy
> if it's relevant or not. Such as not taking into account surfaces that
> are not shown.
> 
> If/when this becomes a problem it can also have an indicator somewhere
> which shows that the screensaver is inhibited and expands to a list of
> surfaces that inhibit it on click or whatever.

Yes, all that makes sense, but how does it relate to the app freezing?
I thought "client locks up" referred to the client freezing, as in,
becoming unresponsive. My misunderstanding?


> >> >> 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.
> >
> 
> This is usually the case with remote desktop access applications. They
> do not show anything, move the cursor without the user touching any
> actual input device, and inject keypresses without the user actually
> touching any input device buttons. There are also those
> multi-computing applications that do not actually capture the screen
> content but allow single input device to control multiple computers
> using physically adjacent screens.

That is not what I was describing. You describe how an arbitrary
process takes control of the compositor by feeding it fake input. I am
talking about a normal application, that happens to show a window
showing a desktop of somewhere else.

Such a hijack application you describe would be feeding the compositor
with fake input in any case, it won't need any inhibitor functionality.

> On the other hand, if it's easy to accomplish the remote control
> application can just implement a virtual input device driver that
> models the remote device and sends actual input events that reset the
> idle timer as much as any other input event delivered.

That's how your case would work. Or more likely explicit support
programmed into the compositor.


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