[RFC] Screensaver/blanking inhibition

Bryce Harrington bryce at osg.samsung.com
Thu Nov 19 13:14:46 PST 2015


On Thu, Nov 19, 2015 at 12:12:10PM -0800, Bill Spitzak wrote:
> On Thu, Nov 19, 2015 at 11:12 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > Hi,
> >
> > On 19 November 2015 at 19:05, Bill Spitzak <spitzak at gmail.com> wrote:
> > > I feel like there is no need to tie it to a surface. In Wayland the
> > client
> > > is always notified of any changes to it's state, so it can update the
> > > screensaver object to match. (destruction of the screensaver object
> > would of
> > > course remove the inhibit).
> > >
> > > The surface may be necessary to indicate if only one output is to have
> > the
> > > screensaver inhibited, but I think wayland clients are aware of which
> > output
> > > their surfaces are on so instead the output could be indicated directly.
> >
> > By default it should be tied to a surface.
> >
> 
> Yes I believe that will work, but will it be possible to inhibit the
> screensaver without putting anything visible on the screen?
> 
> Probably not a big deal, actually. The only application I can really think
> of for this is to force presentation of some other application that does
> not use the inhibit api, and such a tool may still map some kind of
> (normally invisible) overlay for popup controls, so the inhibit could be
> tied to that.

Yeah, following the principle of "don't design for workarounds" I think
we can ignore that case.  Since that's already in workaround land, it
could do some kludgy invisible 1x1 surface craziness or something if it
had to.

At least for this it is probably worth keeping in mind is that the worst
case isn't that big of a deal - if a given application doesn't support
the inhibit interface it just means the screensaver will come on after
some idle period.  If the user finds it annoying enough, the easiest
workaround for them is to just disable or delay the screensaver timeout.

I imagine for legacy X applications, support for inhibit could be
plumbed into Xwayland, possibly leveraging the existing DBUS inhibit
method in some fashion or something.  For Wayland native apps, the
proper fix would obviously be extending the app to use this api.

Bryce


More information about the wayland-devel mailing list