[PATCH weston v3 0/8] Implement screensaver/idle inhibition

[Bryce Harrington]

On Fri, Apr 08, 2016 at 10:41:45AM -0700, Bill Spitzak wrote:
> On Thu, Apr 7, 2016 at 4:44 PM, Bryce Harrington <bryce at osg.samsung.com>
> wrote:
> 
> > This patchset implements screensaver inhibition for Weston (see separate
> > wayland-protocols patch).
> >
> > The first three patches set up some infrastructure adjustments that will
> > be needed in the latter patches.  This makes 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.
> >
> 
> 
> > Patches 5, 6, and 7 shift the shells to use the new functionality.  Each
> > shell can make it's own decision as to what 'active' means, but this
> > just sets the assumption to "has the keyboard focus".
> >
> 
> I don't want the screen displaying the movie to fade out just because I
> went to the other screen and started typing an email.
>
> Instead clients should indicate whether they are "active" by enable and
> disable of inhibition. If a client wants keyboard focus to mean "active",
> the client can turn on inhibition when it gets keyboard focus, and turn it
> off when it loses it.
> 
> I suppose my example could be solved by having a "movie watching seat" but
> that seems excessively complex, especially if that seat has no input
> devices.

Hi Bill,

Yeah agreed some would find it awkward to find screens blanking while
they're actually using the system like you describe - fortunately
though, that wouldn't happen.

This patch moves input idle to be tracked per-seat rather than
compositor-wide.  However, it still treats *any* input as blocking the
screensaving behaviors.  So in other words, your typing in the email on
the one screen is enough to keep any screensaver from coming on at all.

Now, we could probably find some other corner cases where things do
start behaving against expectations.  Like passively watching a long
movie while having the cast list displayed on a secondary screen.  Only
one of these clients would be 'active' (here, it's whichever one was
left with keyboard focus before the user became passive), so after the
configured idle time passes one or the other of the screens will fade.

One thing we have to keep in mind is that the notion of 'active' is a
weston-internal detail, not specified in the protocol.  So other
compositors can explore various other ways to better polish the
usability for cases like these.

Also, even for Weston defining 'active' to be keyboard focus is rather
loose in the sense that each shell has the freedom to define it their
own way.  So for instance, maybe in a desktop-focused shell it might set
'active' to mean something like "any client covering more than 50% of
the screen", or "the last three clients the user interacted with", or
whatever else you can imagine.  For this patchset I've left it as just
vanilla keyboard focus as it is already, but agree there's room here for
followup work to improve things as new ideas come along.

Bryce