[PATCH wayland-protocols v3] Add screensaver idle inhibitor protocol

[Bryce Harrington]

On Mon, Jun 06, 2016 at 10:08:00AM -0500, Yong Bakos wrote:
> On Jun 6, 2016, at 7:18 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >> I don't believe this is a good choice. Imagine the case of a surface-less
> >> 'inhibitor daemon.'
> > 
> > An ordinary client must not be able to do that.
> > 
> >> There may be no visible surface (is my thinking out
> >> of scope here?). Imagine another case, that of a "caffeine" widget. This
> >> widget's surface would be hidden when another app is fullscreen.
> > 
> > If you cannot see the widget anyway, it must not be able to affect
> > screen saving. Therefore by definition, surfaceless clients must not be
> > able to inhibit.
> > 
> >> Furthermore, I don't believe that inhibition should be coupled to outputs.
> >> See below.
> > 
> > It should work per-output. If there is important info on just one
> > output, why should the other outputs also stay on for no good reason?
> 
> Just because I'm looking at info on one monitor doesn't mean I want my other
> monitors to go to sleep.

Not quite, there's actually three different situations to consider

First is if you're watching one monitor and doing something else on the
other.  Like watching a movie while browsing emails.  In this case, your
other usage is going to be generating input activity, and the system
isn't going to be idling to sleep in the first place, so inhibition
simply isn't relevant.

Next consider if you're passively watching two things at once, one
client on one screen and another client on the other.  Maybe you're
monitoring a security camera on one screen and watching live stock
tickers on the other or something.  Well, this is completely in scope of
the idle inhibit design - each client issues an idle inhibit request and
you're good to go.

Finally consider you're watching something on one and *not* doing
anything on the other.  In this case, the second head *should* power
save when appropriate.

State of the art for most screensaver inhibitor tech addresses the
second situation, but leaves the third unsolved.  We should be able to
handle the set.

> I can imagine this being specified via a shell's
> screensaver/power savings config panel, with a checkbox enabling "idle per screen" or "idle
> all screens in unison." So I think this is a moot point.

Exactly - in practice there are generally out-of-band ways to control
screensavers and DPMS and so forth.  I'm trying to avoid making any
assumptions that they exist or are usable, but at least for cases in
where a given client hasn't implemented idle inhibition, or is broken
for some other reason, the user is going to have options.  The protocol
doesn't need to design for non-supporting clients.

> However, I don't believe that just because a surface is occluded, that
> it's ability to inhibit idling should be suppressed.

It's entirely possible; I don't claim to be prescient about all the
various use cases that may exist.  But that would be a pretty
fundamental change, so lets only consider it if there are likely use
cases that just can't be addressed with what we've got so far.

Like I mentioned earlier, we've actually taken a few things *out* of the
protocol because we just lacked rational use cases for them, and because
its easy to add more functionality later but much much harder to remove
functionality that proves unnecessary later.

> >> I don't believe that inhibition should /only/ be coupled to outputs.
> >> In the case of a "caffeine" widget or daemon, the use case is to
> >> prevent /all/ outputs from idling, regardless of what output the widget's
> >> surface resides upon.
> > 
> > That is explicitly not what we want to enable.
> > 
> > What is this "caffeine" you talk about? I've never heard of it. Maybe I
> > never had to fight against screen saving.
> 
> Here's a screenshot of the Gnome-flavored implementation of the widget:
> http://tinyurl.com/caffeine-widget-2
> 
> OSX and others have something similar. This program visually resides in the
> menubar/taskbar of the shell. It has two states, on and off. On (caffeinated)
> overrides the configured screensaver/sleep idle timeout, preventing /all/
> monitors from idling. In the off (un-caffeinated) state, the system behaves
> according to configuration.
> 
> Use case: I've configured my system to screensave at 5 minutes and put the
> monitors to sleep at 10 minutes. But sometimes, I want to override this
> without going in and changing my config, only to have to change it back
> later. I run the caffeine widget, turn it on, and all my monitors remain on
> despite me not interacting with my machine. This behavior remains valid
> even if I am running a program fullscreen, which occludes the visibility
> of the widget.
> 
> It sounds like, from what Bryce had wrote in a separate reply, such a
> widget would use a different API and not this idle inhibitor protocol. I
> might be misunderstanding his point.

Right, idle-inhibit is a functionality that is automatic and
per-client.  What you're describing here is a *manual* and *global* way
of letting the user change the screensaver settings.  So like imagine in
weston this would effectively be a run-time API for setting --idle-time.

So, maybe in the same class as idle-inhibit but a totally different
functionality.  I'd like to imagine idle-inhibit makes such a
functionality unnecessary, but regardless it'd be a different
discussion.

(As an aside, such a function *probably* should not be made available to
arbitrary clients since it is changing a global setting; it probably
would fall in the same category as screen reconfiguration or screen
capture and require special privileges.  And as such it would almost
certainly have to be a compositor-specific thing, and thus likely
implemented over DBUS or however else the compositor handles config
setting type functionality.)

> >> Forgive me if I didn't quite grok prior conversations about this protocol.
> > 
> > It seems like your mindset is tuned to fighting against bad
> > screensaving policies in a compositor, while Bryce's goal with the
> > extension is to allow implementing proper and good screensaving policies
> > *in the first place*, so that no fighting is needed.
> > 
> > We want the compositor to behave correctly, not offer tools to override
> > the compositor behaviour. Bugs should be fixed at their source, not
> > worked around at every other place.
> 
> I hear you. Not fighting, per se, but rather 'temporarily override'.
> I'm just stating that an application should be able to inhibit idling:
> 
> a) On all outputs
> b) Whether it is visible or not
> 
> Per the use case I described above. Whether it uses this inhibitor protocol
> or some other API is fine. But if such a use case /should/ use the inhibitor
> protocol, then the per-output constraint and visibility constraint in the
> protocol would make this functionality 'impossible'.

That's a really good indication that these are two distinct
functionalities, and shouldn't be conflated together.

Bryce