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. Also the protocol should probably cover the cases when a client locks up. 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. >>>> Makes sense ("potentially" could inhibit other things depending on scope >>>> and how it grows) >> >> Absolutely it should by default inhibit any kind of notifier or any other >> changes to the display not triggered by the user (it also should NOT inhibit >> changes that the user triggers, such as hitting a shortcut key that creates >> a popup). >> >> Among these changes that must be inhibited are "things that have not been >> invented yet but may appear in a future desktop". Therefore a per-thing api >> to inhibit them is not going to work and this must inhibit them all. >> >> The api can be enhanced in the future if you want finer control over what is >> inhibited. > > No. People want to receive notifications whilst they watch movies. At least some people sometimes, yes. Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel