<div dir="ltr">On Thu, Nov 19, 2015 at 2:38 AM, Christopher Michael <span dir="ltr"><<a href="mailto:cpmichael@osg.samsung.com" target="_blank">cpmichael@osg.samsung.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, after issuing the inhibit request for a surface, the screensaver<br>
(and screenblanking) will be blocked until the surface is destroyed,<br>
disabled, or otherwise loses visibility or becomes occluded.<br></blockquote></blockquote></blockquote></blockquote></blockquote></div></div></blockquote><div><br></div><div>Will it be possible to inhibit the screensaver without putting anything visible on the screen? I can imagine some programs doing this.<br><br></div><div>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).<br><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In X11, various getter functions are provided for the application to<br>
poll inhibition status.  For Wayland, instead of getters, the current<br>
state is just be pushed to the client when the inhibitor global is<br>
bound, and then updates pushed if/when the status changes.<br>
<br>
</blockquote>
<br>
This makes sense, and follows "standard" wayland practice<br></blockquote></blockquote></blockquote></blockquote></div></div></blockquote><div><br></div><div>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.<br> <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A corresponding uninhibit API will be added as well.  For example, a<br>
movie player may wish to inhibit while a video is playing but<br>
uninhibit<br>
when it is paused.<br></blockquote></blockquote></blockquote></blockquote></blockquote></div></div></blockquote><div><br></div><div>The screensaver object should have several requests. One of them turns the inhibit on/off.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes I think it makes sense to add this to its own extension. A<br>
"wp_inhibiter" in a inhibiter XML file that inhibit things.<br></blockquote></blockquote></div></div></blockquote><div><br></div><div>Please don't use any name that does not have the word "screensaver" in it, because that is the word programmers are going to look for. My suggestion is "wpz_screensaver_v1" (or whatever the rules for experimental protocols are). I suspect this api will quickly get enhanced with other api (such as events when the screensaver turns on/off), so I would not use the word "inhibit" at all.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Makes sense ("potentially" could inhibit other things depending on scope<br>
and how it grows)<br></blockquote></div></div></blockquote><div><br></div><div>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).<br><br></div><div>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.<br><br>The api can be enhanced in the future if you want finer control over what is inhibited.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not so sure about the scope though. If its not about surfaces on outputs<br>
or input devices or focus or display protocol things it should just be a<br>
D-Bus protocol.<br></blockquote></blockquote></div></div></blockquote><div><br>No please don't! It has to inhibit everything by default that you would think that a program trying to disable the screensaver is also trying to disable. It does not matter where or how they are implemented.<br><br></div></div></div></div>