On 20 November 2015 at 11:39, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 19 Nov 2015 22:46:06 +0100 > Michal Suchanek <hramr...@gmail.com> wrote: > >> On 19 November 2015 at 20:12, Daniel Stone <dan...@fooishbar.org> wrote: >> > Hi, >> > >> > On 19 November 2015 at 19:05, Bill Spitzak <spit...@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. > >> 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). Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel