[RFC wayland-protocols v2] Add screensaver inhibition protocol

[Pekka Paalanen]

On Tue, 24 Nov 2015 23:24:55 -0800
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Wed, Nov 25, 2015 at 08:09:16AM +0100, Michal Suchanek wrote:
> > Hello
> > 
> > On 25 November 2015 at 07:49, Bryce Harrington <bryce at osg.samsung.com> wrote:  
> > > This interface allows disabling of screensaver/screenblanking on a
> > > per-surface basis.  As long as the surface remains visible and
> > > non-occluded it blocks the screensaver, etc. from activating on the
> > > output(s) that the surface is visible on.
> > >
> > > To uninhibit, simply destroy the inhibitor object.
> > >
> > > Signed-off-by: Bryce Harrington <bryce at osg.samsung.com>
> > > ---
> > >  Makefile.am                                        |  1 +
> > >  unstable/screensaver-inhibit/README                |  4 ++
> > >  .../screensaver-inhibit-unstable-v1.xml            | 80 ++++++++++++++++++++++
> > >  3 files changed, 85 insertions(+)
> > >  create mode 100644 unstable/screensaver-inhibit/README
> > >  create mode 100644 unstable/screensaver-inhibit/screensaver-inhibit-unstable-v1.xml

> > > diff --git a/unstable/screensaver-inhibit/screensaver-inhibit-unstable-v1.xml b/unstable/screensaver-inhibit/screensaver-inhibit-unstable-v1.xml
> > > new file mode 100644
> > > index 0000000..4252baf
> > > --- /dev/null
> > > +++ b/unstable/screensaver-inhibit/screensaver-inhibit-unstable-v1.xml

> > > +      Note that in the case of a compound window (a surface with
> > > +      sub-surfaces), a separate inhibitor object may be needed for each
> > > +      wl_surface.  
> > 
> > This should not be required. If there is no way to connect the
> > sub-surfaces on the compositor side it can be handled by a toolkit
> > library at worst.  
> 
> pq seemed to think it would be (c.f. previous RFC discussion).  However
> my own understanding of sub-surfaces is fairly shallow, so I don't grok
> all the implications of how inhibition should behave with them.  I would
> have assumed the main surface's inhibit would be sufficient to cover the
> sub-surfaces.

It could be implied with sub-surfaces, yeah, it didn't come to my mind.
This would be an interaction between two extensions, and probably best
documented here than in the sub-surface spec.

It's pretty obvious that if you set the inhibitor on the root surface
of a sub-surface tree, it should affect the whole tree.

From that, we can derive what should happen if you set the inhibitor on
a sub-surface rather than the root: all the descendants of that
sub-surface should be affected too, but siblings or ancestors not.

Does that sound good?


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