[RFC] Screensaver/blanking inhibition

[Christopher Michael]

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

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

> 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

> Bryce
>
> 1: http://lists.freedesktop.org/archives/xdg/2006-June/006523.html
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>