[RFC] Screensaver/blanking inhibition

[Pekka Paalanen]

On Thu, 19 Nov 2015 18:15:39 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

> On Thu, Nov 19, 2015 at 02:04:36AM -0800, Bryce Harrington wrote:
> > On Thu, Nov 19, 2015 at 04:20:11AM -0500, Christopher Michael wrote:
> > > 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[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.
> > > >
> > > 
> > > Is the protocol going to be in "wayland" or in "weston" ??
> > 
> > I imagine like other protocols it'll gestate in weston (actually
> > probably the new wayland-protocols repository), and hopefully eventually
> > move into the wayland repository.
> 
> Actually, the intention is to keep stable protocols in
> wayland-protocols. The only protocol type of things that would be added
> to the wayland repository are core protocol additions, and except for
> new requests/events to existing interfaces I don't have an example or
> idea of what type of protocol that would be.
> 
> 
> > But I'm sketchy on where exactly this
> > should be placed initially, so am hoping to get some advice there.
> 
> I'd say a screensaver-inhibit if its just about screenblank/lock/.. or
> inhibiter if its about inhibiting anything. I don't see a need of
> making it "xdg" because its can just as well, as you already mentioned,
> be usable for ivi and other things where there is no desktop but still
> clients who should inhibit the screen blanking.

There is one fundamental decision to be made that determines whether
this is an xdg extension or not.

Do you attach the inhibitor to a wl_surface or an xdg_surface?

Both have pros and cons:

wl_surface:
+ truly generic, does not depend on any particular shell
. could be used on funny things, like cursors
- if you have a compund window (uses sub-surfaces), you may need an
  inhibitor for each wl_surface

xdg_surface:
- dependant on xdg_shell (might be unusable for e.g. KDE, jugding from
  the recent comments in Martin's blog)
. only applicable to real top-level windows: xdg_surfaces
+ compound windows need only one inhibitor object

Personally I would lean on wl_surface here because it is generic, and
the downsides I could think of are minor.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151120/d7fbb55f/attachment.sig>