[RFC] Screensaver/blanking inhibition

[Bryce Harrington]

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.  But I'm sketchy on where exactly this
should be placed initially, so am hoping to get some advice there.

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

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