[RFC] Screensaver/blanking inhibition

Thu Nov 19 02:15:39 PST 2015

On Thu, Nov 19, 2015 at 02:04:36AM -0800, Bryce Harrington wrote:
> On Thu, Nov 19, 2015 at 04:20:11AM -0500, Christopher Michael wrote:
> > Just some random thoughts inlined below...
> > 
> > On 11/19/2015 03:05 AM, Bryce Harrington wrote:
> > >A "screensaver inhibition protocol" is on the set of needed enhancements
> > >for Wayland.  This should turn off screen blanking and any running
> > >screensaver for a period, then re-enabling it later.
> > >
> > >An obvious use case is giving presentations.  Other use cases include
> > >games, kiosk, automotive infotainment systems.
> > >
> > >I'd like to take a shot at defining the protocol for this and
> > 
> > Yay !! :)
> > 
> > >implementing it for Weston.  The design I have in mind mostly follows
> > >xdg-screensaver and the DBUS screensaver API[1], which provide a
> > >desktop-neutral 'inhibit' mechanism to temporarily disable the
> > >screensaver/screenblanker on a per-process basis, except that it will be
> > >per-surface instead of per-process.
> > >
> > 
> > Is the protocol going to be in "wayland" or in "weston" ??
> 
> I imagine like other protocols it'll gestate in weston (actually
> probably the new wayland-protocols repository), and hopefully eventually
> move into the wayland repository.

Actually, the intention is to keep stable protocols in
wayland-protocols. The only protocol type of things that would be added
to the wayland repository are core protocol additions, and except for
new requests/events to existing interfaces I don't have an example or
idea of what type of protocol that would be.

> But I'm sketchy on where exactly this
> should be placed initially, so am hoping to get some advice there.

I'd say a screensaver-inhibit if its just about screenblank/lock/.. or
inhibiter if its about inhibiting anything. I don't see a need of
making it "xdg" because its can just as well, as you already mentioned,
be usable for ivi and other things where there is no desktop but still
clients who should inhibit the screen blanking.

> 
> > >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.
> > >
> > >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
> > 
> > >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.
> > >
> > >Inhibition can be specified as display-specific or global.  If it is set
> > >as display-specific, then only the display(s) the surface is visible on
> > >will be inhibited and other displays will powersave normally.  If it is
> > >global, then it affects all displays.  We don't give clients the ability
> > >to set inhibition arbitrarily on displays - it will only take effect for
> > >display(s) where the surface is actually shown.
> > >
> > >Questions:
> > >
> > >a.  Which protocol file should this stuff be added to?  Weston's
> > >     desktop-shell.xml (soon to be renamed weston-desktop-shell.xml) has
> > >     a screensaver interface, but that is only weston-specific, yet we
> > >     want this functionality to work on multiple compositor
> > >     implementations.
> > >
> > 
> > xdg-screensaver.xml maybe ??
> 
> Ah, I was thinking the requests should be added to one of the existing
> protocol files, but hadn't thought maybe it should go into its own xml
> file.  Hmm...

Yes I think it makes sense to add this to its own extension. A
"wp_inhibiter" in a inhibiter XML file that inhibit things.

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.

Jonas

> 
> > >b.  Do we need to handle inhibition for screensavers (i.e. the interface
> > >     in desktop-shell.xml) separately from screen blanking.  I don't see
> > >     anyone needing to inhibit one without also wanting to inhibit the
> > >     other too, so it would be nice to have a single request that covers
> > >     any sort of screen obscurement.
> > >
> > 
> > I think that as long as what you come up with can handle
> > screensaver, blanking, (and maybe dimming ??) then it should be
> > sufficient.
> > 
> > >c.  For X, in addition to inhibition, several other methods are provided
> > >     to client applications to control aspects of the screensaver and
> > >     display power savings.  E.g. 'Poke' to simulate user activity,
> > >     deliberately activating the screensaver, or locking, or power
> > >     savings, etc.  Do we need/want any of these for Wayland too?
> > >
> > 
> > Perhaps a "request" to activate, lock, etc, etc .. then maybe it's
> > up to the compositor to allow or not ?
> > 
> > >d.  When giving a presentation, there are several other things one may
> > >     want to inhibit besides the screensaver, such as notifications,
> > >     sound effects, background music, etc.  The above proposal assumes
> > >     inhibition of each of these is handled separately some other way,
> > >     but do we want to consider some more generalized solution?
> > >
> > 
> > My initial thought would be a generic "inhibit" request, or perhaps
> > an "inhibit all" ... then let the compositor deal/decide.
> > 
> > Cheers,
> > Chris
> 
> Thanks,
> Bryce
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel