[PATCH wayland-protocols v3] Add screensaver idle inhibitor protocol

[Bryce Harrington]

On Wed, Jun 08, 2016 at 12:02:14PM +0300, Pekka Paalanen wrote:
> On Wed, 8 Jun 2016 10:51:30 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > On Tue, Jun 07, 2016 at 07:10:25PM -0700, Bryce Harrington wrote:
> > > On Fri, Jun 03, 2016 at 09:26:24AM +0800, Jonas Ådahl wrote:  
> > > > On Thu, Jun 02, 2016 at 02:24:20PM -0700, Bryce Harrington wrote:  
> > > > > +      Note that in the case of a compound window (a surface with
> > > > > +      sub-surfaces), the inhibitor effects should be inherited from the top
> > > > > +      level surface.  
> > > > 
> > > > Does this mean that if we have a subsurface with an inhibitor object,
> > > > and for example an xdg_surface without one, the subsurface would still
> > > > not inhibit the idle behavior, as it'd inherit the behavior?
> > > > 
> > > > If it should work like this, maybe we should make it an error to create
> > > > an idle inhibitor on a subsurface. If it should inhibit, I think it
> > > > needs to be clarified.  
> > > 
> > > Well, I suppose we should consider likely use cases here.
> > > 
> > > Is video-in-browser considered one of the big uses for subsurfaces?
> > > Here's a couple use cases off the top of my head:
> > > 
> > > a) I want to watch a video embedded in a web page.  I typically maximize
> > >    the video so I can see it well.  I would expect the screensaver to
> > >    not kick on for the duration of this video.  Once I'm done with it
> > >    and go back to regular web browser usage, I want my screensaver to
> > >    work normally.
> > > 
> > > b) I'm surfing the web reading articles on some annoying site that
> > >    auto-plays videos for me.  Maybe it's an advertisement, or maybe just
> > >    a live video news report version of the news article I'm reading.  I
> > >    just ignore it because I don't care.  When the video is done, it
> > >    automatically plays the next advertisement or video.  These videos
> > >    are annoying enough themselves, I definitely do not want these videos
> > >    causing my screensaver to not kick in.
> > > 
> > > So based on this I'm thinking subsurfaces probably should not be allowed
> > > to automatically override the parent.  But if the user takes some action
> > > that can be interpreted as "I am focusing on this subsurface" such as
> > > maximizing it or making it larger or something, then in that case I
> > > could see permitting it to inhibit.  
> > 
> > I don't think we should start to adding things about focusing
> > subsurfaces. I also don't think we should really try to solve good vs
> > bad videos in a browser in the protocol.

Neither of which was I doing.  Perhaps you're misunderstanding my use of
'focusing' to mean something technical like mouse focus, when all I'm
saying is "the user is actually looking at it."  And I don't see how you
are possibly interpreting my speculative example into some sort of
absurd proposal to fix bad internet videos.  You're just building a
strawman argument here, rather than helping me get to a tangible use
case where inhibition in relation to subsurfaces are actually of some
utility.

> > > Is a maximized subsurface still a subsurface or does it become a parent
> > > level surface?  If it does, then I think we can just let maximization be
> > > the indication to allow inhibition, and otherwise just not let
> > > subsurfaces interfere with their parent settings.  But if it doesn't,
> > > then perhaps we need a more sophisticated mechanism here.  
> > 
> > There is no such thing as a maximized subsurface. We maximize or
> > fullscreen a shell surface, and the client updates its subsurface
> > accordingly. I don't think we should mix in shell surface behavior in
> > this protocol, we should just trust the web browser to protect us from
> > nasty web page behaviors, and let it inhibit things the way it sees fit.
> 
> Also agreed.
> 
> Furthermore, one cannot use any shell concepts in defining the
> idle-inhibit extension, because idle-inhibit is a sibling, not a child
> extension to shells. If you need to use those concepts, then you need
> define them or make this a shell-extension-specific extension.

Jonas' question was for how this would work in a larger context, for
instance with xdg_surface.  This is not a proposal, and I'm quite aware
of the need to keep this agnostic of shell behavior, so no need for
pedagogy on that point.

> > The decision we need to make is: should we allow subsurfaces to inhibit
> > idle behavior, and if so, do they override their parent, or inherit it.
> > I suspect as long as we allow subsurfaces to affect the inhibit
> > behavior, we'll allow clients to construct their surface trees so that
> > they can get the inhibit behavior they want. Well, except if they don't
> > use subsurfaces for video content. If we care about that we'd need add
> > inhibit behaviour for sub regions of surfaces.
> 
> I think sub-regions go too far.
> 
> Sub-surfaces however would be necessary to take into account somehow,
> because you can construct a window from several non-overlapping
> sub-surfaces, and hang parts of the window on different outputs.
> 
> Therefore I think inheritance is necessary. Overriding is possible only
> in the direction of adding an inhibitor.
> 
> OTOH should we deny setting inhibitors on sub-surfaces? IOW, should we
> deny based on the surface role? If yes, does a surface have to have a
> role before creating an inhibitor? What if it doesn't and you make it a
> sub-surface afterwards?
> 
> What if someone adds new surface roles in the future? A different kind
> of sub-surface maybe because they hate the current interface?
> 
> I think the simplest solution here is:
> - inherit inhibition
> - do not forbid inhibitors based on surface role
> 
> However, should inheritance be limited to sub-surfaces only, that is,
> based on role? What about parent-child relationships established in
> e.g. xdg_shell? Ok, so inheriting becomes a bit hard too.
> 
> Rethinking this, should we actually not spec anything about inheritance
> in this extension, and instead say it in sub-surface spec?
> In more generic terms, where does extension interoperability
> documentation belong? I don't think there is a single answer to that,
> we have to go case by case with where it makes most sense.
> 
> To explain that inhibition could be inherited, I propose the
> idle-inhibit spec specifies inheritance for sub-surfaces only. Then if
> e.g. xdg_shell or something would like to do the same, it can refer to
> the sub-surface case as a precedent.
> 
> Yes, this is overthinking things.
>
> I stick to my simplest suggestion:
> - inherit inhibition for sub-surfaces (by effectiveness, not by
>   pretending the child has its own copy of the inhibitor to be
>   evaluated separately)
> - do not forbid inhibitors based on surface role
> 
> Otherwise we could discuss this to the death.

We seem to already be doing this.

Frankly, I don't care one way or the other whether subsurfaces is even
addressed in the protocol.  I included it at your request, in hopes it
would make the protocol more landable, but honestly have never really
understood what the point of it is for - thus my pushing for getting a
tangible use case defined.  If that use case is so far from validity,
then it really makes me think maybe this version of the protocol should
just sidestep the question of subsurface behavior and leave it as follow
up work, particularly after seeing the variety of questions and opinions
that have been popping up.

But if you feel strongly that subsurfaces *must* be addressed in the
protocol, then let me request this - provide me with *exact* text to
paste in to replace that last paragraph.

Bryce