[RFC] Screensaver/blanking inhibition

[Pekka Paalanen]

On Thu, 19 Nov 2015 13:02:24 -0800
Bryce Harrington <bryce at osg.samsung.com> wrote:

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

Hi Bryce,

I whole-heartedly agree 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.

This I agree except on the systemwide. "Unless systemwide" sounds like
you are contradicting your own design, and I use your own rationale
against that:

Why would an app care about an output it is not showing anything on?

Unless someone can give a good use case for that which is not just a
hack around broken apps or broken compositors, I'd say there should not
be a systemwide option at all.

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

Agreed. The compositor knows exactly on which outputs the surface is
showing on, so there is no need to first tell the client where the
surface is and then wait for the client to copy that info back to the
compositor. That would be just stupid.

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

Yeah. Let's start with the strictly surface-tied method, and see if
anything falls out.

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

I'm curious, what is any of that information useful for?

Somewhat relatedly, I don't think requests like start a screensaver or
lock the screen or "poke" belong in this extension. I do not see what
use they would have in all the cases where inhibitor is useful.

I took a quick look at the DBUS screensaver API you linked to, and to
me it seems like it is written for an external power manager daemon or
something. I think that is mostly off-topic for the generic inhibitor
protocol.

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

Daniel gave a perfectly working and simpler design for turning inhibit
off: destroy the surface-specific inhibitor object.

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

Right.

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

The screensaver interface (now weston_screensaver) is a Weston desktop
shell internal implementation detail that allows the desktop-shell to
recognize a wl_surface as a screensaver window. Functionally it is
completely irrelevant to this discussion. Think of it as the same as
the private protocol between desktop-shell.so and weston-desktop-shell.


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

I'm not sure I see the connection there. Any fullscreen (rather than
maximized) app might want to prevent notifications, but not necessarily
the screensaver/lock. Why would screensaver and notifications be handled
in the same?

Besides, if the inhibitor is made generic rather that depending on
xdg_shell, there is no concept of a notification or anything else like
that at all. Trying to shove desktop concepts into a generic,
non-desktop extension just doesn't make sense.

Turning outputs off is a generic concept applicable to any display
server.

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

Let's keep it simple for starters, and focus on the concept of turning
outputs off. That is common for all display servers, also non-desktop.

On desktop, turning outputs off is a sort of an umbrella for
screensavers, screenlocks, and DPMS: stuff that makes the normal view
go away due to lack of user interaction.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151120/e43235be/attachment.sig>