[RFC weston 00/10] Implement screensaver inhibition

Bryce Harrington bryce at osg.samsung.com
Sat Mar 5 00:18:37 UTC 2016

This patchset implements screensaver inhibition for Weston.  It
implements the protocol RFC proposed earlier:


The first three patches set up some infrastructure adjustments that will
be needed in the latter patches.  We make idle behavior tracked on a
per-seat basis, so that shells can connect an inhibit on an active
surface with the seat generating the input events for that surface.
Surfaces gain parameters for tracking inhibition requests from clients,
and tracking activity as defined by shells.

The fourth patch integrates these bits to implement the core
functionality of per-output idle management.  This fourth patch is the
meat of the patchset.

Next come a series of patches to shift the shells to using the altered
activity functionality.  Essentially, each shell now can define what it
means for a surface to be 'active'.  I've repurposed
weston_surface_activate() to specify this now; before it was used mainly
to change the keyboard focus.  I've left it with this keyboard focusing
functionality but wonder if maybe that should be broken out separately.
I'm also uncertain if the choices I've made for each shell are exactly
appropriate, so would especially appreciate detailed review of the shell

Next come the actual client and server protocol implementation.  With
these, clients are able to specify inhibition and the server will honor
it.  Along with the client protocol, I've included an example
implementation for the simple-shm client.  I find it useful to run
weston with a shorter idle timeout, e.g. `weston -i5`.

The final patch adjusts how the fade-out animation works in
desktop-shell.  This is still a bit WIP and has some buglets I'm not yet
certain how to fix.  Essentially, instead of having a single surface
across all outputs to do the fade-out animation, we create one for each
output, and prevent them from firing on outputs with valid inhibitions
on them.  However, unfortunately when the inhibiting client exits, it
doesn't re-trigger the animation; after terminating the inhibiting
client, you have to wiggle the mouse or give some input so the idle
cycle triggers again.  There's probably other corner cases...  For now
I'm just looking for some guidance on whether this last patch is going
in the right direction.

Lastly, while implementing this patchset, I've decided I dislike the
protocol API names.  '*_inhibition_inhibit_*' is just plain cumbersome,
and I feel makes some of the variable and function names confusing.
Also, while there was consensus that including 'screensaver' in the
protocol name would help users better understand what this is,
technically the patchset has nothing to do with literal screensavers so
feels awkward.  I'm contemplating perhaps naming the global something
like "the idle manager" with the inhibition request being named something
like "an idle inhibitor".  I'll propose a followup RFC to my protocol
patch, to spark discussion on this.

Bryce Harrington (10):
  compositor: Track idle as a per-seat property
  compositor: Track inhibition state in weston_surface
  compositor: Track surface activity
  compositor: If the output is inhibited, don't idle it off
  desktop-shell: Support tracking active surfaces
  fullscreen-shell: Support tracking active surfaces
  ivi-shell: Support tracking active surfaces
  Define the screensaver inhibition server interface
  Define the screensaver inhibition client interface
  desktop-shell: Enable per-output fade animations

 Makefile.am                         |  13 ++-
 clients/simple-shm.c                |  29 +++++-
 desktop-shell/shell.c               |  94 ++++++++++-------
 fullscreen-shell/fullscreen-shell.c |  36 ++++++-
 ivi-shell/ivi-shell.c               |  10 ++
 ivi-shell/ivi-shell.h               |   2 +
 src/compositor.c                    | 202 ++++++++++++++++++++++++++++++++++--
 src/compositor.h                    |  32 +++++-
 src/input.c                         |  54 +++-------
 9 files changed, 374 insertions(+), 98 deletions(-)


More information about the wayland-devel mailing list