[RFC] Screensaver/blanking inhibition
cpmichael at osg.samsung.com
Thu Nov 19 01:20:11 PST 2015
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, 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.
> 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
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.
> 1: http://lists.freedesktop.org/archives/xdg/2006-June/006523.html
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel