[RFC] Screensaver/blanking inhibition

[Derek Foreman]

On 24/11/15 12:46 PM, Bryce Harrington wrote:
> On Mon, Nov 23, 2015 at 11:51:07AM -0800, Bill Spitzak wrote:
>> I now agree that tying the inhibit to a surface is exactly the right thing
>> to do.
>>
>> Besides preventing blanking of only the correct output, this could also
>> allow the compositor to show popup notifications when the compositor knows
>> they will not interfere with the surface.
> 
> Not sure what you mean here - mind elaborating?
> 
>> I also think there is no need for the "all outputs inhibit". That is just
>> an artifact of how current systems work. I know for a fact that I am
>> annoyed that watching a movie on the tv screen disables the screen saver
>> and thus leaves the desktop monitor on (and projecting a glow against a
>> wall behind the tv) and I physically have to turn that monitor off to fix
>> this. I would guess that disabling the screen saver only on the monitors
>> being used is the desired behavior by everybody, and thus should be the
>> supported. The only reason to blank all of them is technical impossibility
>> of blanking only one of them.
> 
> Hmm, you may be right.  Certainly is an interesting direction to take.
> 
> I'm trying to think of a use case where you have, say, a dual head
> configuration, and are watching something on one monitor but providing
> no input for an extended period of time, and where the second (unused)
> monitor should *not* powersave normally.  I can't think of anything
> fitting that situation, but my gut suggests people are going to want it.

Playing a full screen game on one monitor while a web browser is open
with a cheat guide on the other. :)

In any event, that seems like it should be something a compositor has a
config knob for, not something the protocol has to deal with...


Thanks,
Derek

> Indeed, as you say, most of the cases I can think of are ones where it
> might be disconcerting at first but it *is* what you want technically.
> 
> I suppose this is something that's easier to omit and add later when a
> need proves itself, than to include it from the start and try to remove
> it later.  So I can leave that bit out until someone presents a viable
> use case where it's needed.
>  
>> So it should only inhibit disabling the outputs the attached surface is
>> viewed on.
>>
>> Also my concern about requiring a visible output is I think not a problem
>> for any real application I think.
> 
> Thanks for the reviews!
> Bryce
> 
>> On Fri, Nov 20, 2015 at 6:10 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>>
>>> On 20 November 2015 at 14:43, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>>> 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?
>>>
>>> It relates to usability quite clearly. When client 'locks up' the
>>> surface remains but the client is no longer showing whatever it was
>>> supposed to show for which the screen was supposed not to blank. Now
>>> since the request is tied to a surface the compositor can decide
>>> automagically or the user by hand that the client is not performing
>>> and either revoke the request or remove the surface entirely.
>>>
>>> In X11 land the inhibit request is delivered through some backyard
>>> protocol that does not tie the request to a particular window so there
>>> is no way to decide that the request can be revoked. When an
>>> application requests that the screensaver be inhibited it may stay
>>> inhibited (and actually actively unblank when blanked) indefinitely
>>> for no apparent reason. If the protocol includes death notification
>>> such as dbus you can end the request by killing the application but
>>> you would have to know which application requested the screen blank
>>> inhibition.
>>>
>>>>
>>>>
>>>>>>>>> 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.
>>>
>>> That's basically not different from a media player. You just have a
>>> different kind of movie.
>>>
>>> Thanks
>>>
>>> Michal
>>>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>