[RFC] Screensaver/blanking inhibition

[Bryce Harrington]

On Thu, Nov 19, 2015 at 11:05:58AM -0800, Bill Spitzak wrote:
> On Thu, Nov 19, 2015 at 2:38 AM, Christopher Michael <
> cpmichael at osg.samsung.com> wrote:
> 
> So, after issuing the inhibit request for a surface, the screensaver
> >>>>>> (and screenblanking) will be blocked until the surface is destroyed,
> >>>>>> disabled, or otherwise loses visibility or becomes occluded.
> >>>>>>
> >>>>>
> Will it be possible to inhibit the screensaver without putting anything
> visible on the screen? I can imagine some programs doing this.

I'm certain I've not thought of every possible use case.  The ones I've
considered would have visible elements on screen though, so I haven't
seen a problem with making that a requirement.  But I would appreciate
hearing about broader use cases that might bring question to that.

I am aware of various display management tools for fiddling with
screensavers (my xdg-screensaver utility would be a case in point).  But
many of these tools (e.g. xrandr, wm-utils, et al) arguably exist to
work around deficiencies or limitations in the window system, and I
gather with Wayland the desire is not to make special cases just for
workaround tools.  E.g. instead of providing an interface for writing
xrandr utilities that the user (or user-side client apps) would have to
use to manually configure displays, the goal is to just make them work
properly to begin with.  The design aesthetic seems to be that the
server should behave "properly" without needing to depend on users,
client apps, or other third party bits to have to fiddle with it.

So in requiring a visible element on screen I'm quite deliberately
excluding provision for those sorts of utility command line tools.

If you can think of things beyond that class, though, I'd love to mull
them over further with you.

> 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).

Certainly, in an ideal world the client could just manage it all.  But
the whole point of inhibit is to provide a way for the screensaver to
get restored independent of the client - in case it crashes, locks up,
or otherwise goes out to lunch.  Again, trying to behave properly
without expecting excessive amounts of sanity client-side.

> 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.

Yes this is a point I'm less certain of, but here's my thinking.

First, like I mentioned in the proposal, I don't like the idea of
applications being able to affect outputs that they aren't displaying
anything on, unless they're doing it systemwide.

Second, imagine an arbitrary client being dragged across several
monitors rapidly.  Can we expect it to reliably uninhibit on the
outputs its exiting, as it issues inhibits on the outputs it's entering?
Could a race condition leave us in a situation where some display's
powersaving is permanently inhibited, for a client that no longer exists
on it?

Third, generally with Wayland it seems like we want to abstract client
awareness of their physical display as much as possible.  So, having
them directly manipulate inhibition for each output doesn't seem to fit
that design style.

Now that said, I'm aware that by making inhibition work more indirectly,
it may well exclude important use cases, or introduce situations where
fundamental bugs can arise.  So I definitely would like to hear more
feedback so we can make sure this doesn't happen.

> 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.

Hmm, I wasn't thinking we'd push status about other clients' inhibition
requests - I agree there'd be a security issue with that.  Rather, the
status would be more like whether the screensaver is on or off, whether
the screen is in standby, suspend, or off, etc.  The X DBUS API also
provides data on how long the screensaver has been running, and how long
the session is idle; I don't know whether to include any of that, but
that's bounds on the scope of data I'm imagining might be included
here.  Nothing client-specific.

> > 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.
> >>>>>>
> >>>>>
> The screensaver object should have several requests. One of them turns the
> inhibit on/off.
> 
> Yes I think it makes sense to add this to its own extension. A
> >>> "wp_inhibiter" in a inhibiter XML file that inhibit things.
> >>>
> >>
> 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.

Yeah agreed with all of that.

The one thing to keep in mind is distinguishing screen*saving*
(e.g. displaying some decorative animation) from screen*blanking* (which
often eventually involves switching DPMS modes).  From an end-user
perspective these are all hand-wavily one and the same, so conceptually
I think inhibit should just take care of them all in a unified fashion.

Anyway, so, "screensaver" may not be the most precise term, but you're
right that this is likely going to be what developers look for, and if
it ends up providing a more comprehensive interface for them, it'll just
be a pleasant surprise.  I'm hoping there's a better term, but haven't
come up with anything.

I do note that there already is a "screensaver" named interface in
weston-desktop-shell, and I would like to avoid conflict or confusion
with it.  (I'm not opposed to doing something that supercedes it... I
seem to recall its functionality is mostly gutted down to stubs now, and
it's not widely used even inside weston, so replacing it might be quite
feasible, if we want to go that route...)

> > 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.

I like the sound of it, and generally agree.

Trick is, though, it's hard to predict what exactly the user is going to
expect to be inhibited vs. what shouldn't be.  For instance, maybe a
user is waiting for a skype call and watches a training video in the
mean time, and wants the latter to inhibit the screensaver but not the
skype call notification.

But you may be right that such corner cases might be best handled via
some future finer control mechanism.  For video playback, the larger use
case likely would want to inhibit notifications (at least non-critical
stuff).

I worry though that at some point here we cross over into defining
behaviors that may be better done as D-E specific logic.  But there's
room to strike a balance.

> Not so sure about the scope though. If its not about surfaces on outputs
> >>> or input devices or focus or display protocol things it should just be a
> >>> D-Bus protocol.
> >>>
> >>
> 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.

Bryce