[RFC] Screensaver/blanking inhibition

Bryce Harrington bryce at osg.samsung.com
Thu Nov 19 00:05:11 PST 2015


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

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.

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.

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.

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?

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?

Bryce

1: http://lists.freedesktop.org/archives/xdg/2006-June/006523.html


More information about the wayland-devel mailing list