Discussion:
[PATCH wayland-protocols v3] Add screensaver idle inhibitor protocol
(too old to reply)
Bryce Harrington
2016-06-02 21:24:20 UTC
Permalink
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 <***@bryceharrington.org>
---

v2:
+ Rename protocol to idle-inhibit
v3:
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq


Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
+Maintainers:
+Bryce Harrington <***@osg.samsung.com>
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
1.9.1
Jonas Ådahl
2016-06-03 01:26:24 UTC
Permalink
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,

I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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.


Jonas
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
1.9.1
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Pekka Paalanen
2016-06-03 09:04:30 UTC
Permalink
On Fri, 3 Jun 2016 09:26:24 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,

you posted the last one marked as v3, so this would have been v4.
Post by Jonas Ådahl
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Yeah, makes sense.
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.

To clarify what I mean, lets consider an artificial case like this:

wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.

wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.

Output 1 will go to powersave: no surface is inhibiting it.

Output 2 does not go to powersave: B inhibitor is in effect.

Output 3 does not go to powersave: C inherits B's inhibitor behaviour.


This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?

That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?

I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.

If you agree with my "inherited from parent" idea instead of from
top-level, you get:
Acked-by: Pekka Paalanen <***@collabora.co.uk>


Thanks,
pq
Yong Bakos
2016-06-03 15:39:24 UTC
Permalink
Hi,
Post by Pekka Paalanen
On Fri, 3 Jun 2016 09:26:24 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
you posted the last one marked as v3, so this would have been v4.
Post by Jonas Ådahl
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Yeah, makes sense.
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
Shouldn't there be a "create" request so clients can obtain the manager object?
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
destroy the idle inhibit manager
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Agreed w/ pq. But, is the inhibit manager a /singleton/ global?
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
Does it make sense to associate inhibitors to surfaces, rather than clients?
See below.
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.' There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.

Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.
wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.
wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.
Output 1 will go to powersave: no surface is inhibiting it.
Output 2 does not go to powersave: B inhibitor is in effect.
Output 3 does not go to powersave: C inherits B's inhibitor behaviour.
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
Post by Pekka Paalanen
This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?
That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?
I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.
If you agree with my "inherited from parent" idea instead of from
Thanks,
pq
Forgive me if I didn't quite grok prior conversations about this protocol.

Thank you,
yong
Bryce Harrington
2016-06-04 19:20:59 UTC
Permalink
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Agreed w/ pq. But, is the inhibit manager a /singleton/ global?
On the client side yes.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
Does it make sense to associate inhibitors to surfaces, rather than clients?
See below.
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.' There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.
This use case did get discussed a bit in previous rounds. But such
tools were felt to essentially be just crude workarounds for lack of
proper API level control over things. Sort of in the same class as why
we don't provide an xrandr-equivalent tool for configuring the monitors
- don't provide tools to work around bad designs, just fix the design so
such tools are superfluous. :-)
Post by Yong Bakos
Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.
wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.
wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.
Output 1 will go to powersave: no surface is inhibiting it.
Output 2 does not go to powersave: B inhibitor is in effect.
Output 3 does not go to powersave: C inherits B's inhibitor behaviour.
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
You're right in gathering that you missed some earlier discussion on
this. :-) In the original RFC this protocol did provide an
"inhibit idle on all-outputs" type function but in earlier reviews there
just wasn't a solid use case for that so I took it out.

I believe the reason software like you mention operate on all monitors
is just that there isn't a convenient API for doing the per-output level
control. Back in the day I suppose it was unusual to have more than one
output, so having finer grained control over screensavers and power
saving modes probably didn't make much sense.

Bryce
Post by Yong Bakos
Post by Pekka Paalanen
This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?
That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?
I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.
If you agree with my "inherited from parent" idea instead of from
Thanks,
pq
Forgive me if I didn't quite grok prior conversations about this protocol.
Thank you,
yong
Pekka Paalanen
2016-06-06 12:18:44 UTC
Permalink
On Fri, 3 Jun 2016 10:39:24 -0500
Post by Yong Bakos
Hi,
Post by Pekka Paalanen
On Fri, 3 Jun 2016 09:26:24 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
you posted the last one marked as v3, so this would have been v4.
Post by Jonas Ådahl
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Yeah, makes sense.
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
Shouldn't there be a "create" request so clients can obtain the manager object?
Hi,

that request is wl_registry.bind, as for all globals.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
destroy the idle inhibit manager
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Agreed w/ pq. But, is the inhibit manager a /singleton/ global?
Yes.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
Does it make sense to associate inhibitors to surfaces, rather than clients?
See below.
Yes, they must be associated to surfaces.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.'
An ordinary client must not be able to do that.
Post by Yong Bakos
There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.
If you cannot see the widget anyway, it must not be able to affect
screen saving. Therefore by definition, surfaceless clients must not be
able to inhibit.
Post by Yong Bakos
Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
It should work per-output. If there is important info on just one
output, why should the other outputs also stay on for no good reason?
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.
wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.
wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.
Output 1 will go to powersave: no surface is inhibiting it.
Output 2 does not go to powersave: B inhibitor is in effect.
Output 3 does not go to powersave: C inherits B's inhibitor behaviour.
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
That is explicitly not what we want to enable.

What is this "caffeine" you talk about? I've never heard of it. Maybe I
never had to fight against screen saving.
Post by Yong Bakos
Post by Pekka Paalanen
This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?
That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?
I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.
If you agree with my "inherited from parent" idea instead of from
Thanks,
pq
Forgive me if I didn't quite grok prior conversations about this protocol.
It seems like your mindset is tuned to fighting against bad
screensaving policies in a compositor, while Bryce's goal with the
extension is to allow implementing proper and good screensaving policies
*in the first place*, so that no fighting is needed.

We want the compositor to behave correctly, not offer tools to override
the compositor behaviour. Bugs should be fixed at their source, not
worked around at every other place.


Thanks,
pq
Yong Bakos
2016-06-06 15:08:00 UTC
Permalink
Post by Pekka Paalanen
On Fri, 3 Jun 2016 10:39:24 -0500
Post by Yong Bakos
Hi,
Post by Pekka Paalanen
On Fri, 3 Jun 2016 09:26:24 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
you posted the last one marked as v3, so this would have been v4.
Post by Jonas Ådahl
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Yeah, makes sense.
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
Shouldn't there be a "create" request so clients can obtain the manager object?
Hi,
that request is wl_registry.bind, as for all globals.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
destroy the idle inhibit manager
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Agreed w/ pq. But, is the inhibit manager a /singleton/ global?
Yes.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
Does it make sense to associate inhibitors to surfaces, rather than clients?
See below.
Yes, they must be associated to surfaces.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.'
An ordinary client must not be able to do that.
Post by Yong Bakos
There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.
If you cannot see the widget anyway, it must not be able to affect
screen saving. Therefore by definition, surfaceless clients must not be
able to inhibit.
Post by Yong Bakos
Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
It should work per-output. If there is important info on just one
output, why should the other outputs also stay on for no good reason?
Just because I'm looking at info on one monitor doesn't mean I want my other
monitors to go to sleep. I can imagine this being specified via a shell's
screensaver/power savings config panel, with a checkbox enabling "idle per screen" or "idle
all screens in unison." So I think this is a moot point. However, I
don't believe that just because a surface is occluded, that it's ability
to inhibit idling should be suppressed.
Post by Pekka Paalanen
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.
wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.
wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.
Output 1 will go to powersave: no surface is inhibiting it.
Output 2 does not go to powersave: B inhibitor is in effect.
Output 3 does not go to powersave: C inherits B's inhibitor behaviour.
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
That is explicitly not what we want to enable.
What is this "caffeine" you talk about? I've never heard of it. Maybe I
never had to fight against screen saving.
Here's a screenshot of the Gnome-flavored implementation of the widget:
http://tinyurl.com/caffeine-widget-2

OSX and others have something similar. This program visually resides in the
menubar/taskbar of the shell. It has two states, on and off. On (caffeinated)
overrides the configured screensaver/sleep idle timeout, preventing /all/
monitors from idling. In the off (un-caffeinated) state, the system behaves
according to configuration.

Use case: I've configured my system to screensave at 5 minutes and put the
monitors to sleep at 10 minutes. But sometimes, I want to override this
without going in and changing my config, only to have to change it back
later. I run the caffeine widget, turn it on, and all my monitors remain on
despite me not interacting with my machine. This behavior remains valid
even if I am running a program fullscreen, which occludes the visibility
of the widget.

It sounds like, from what Bryce had wrote in a separate reply, such a
widget would use a different API and not this idle inhibitor protocol. I
might be misunderstanding his point.
Post by Pekka Paalanen
Post by Yong Bakos
Post by Pekka Paalanen
This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?
That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?
I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.
If you agree with my "inherited from parent" idea instead of from
Thanks,
pq
Forgive me if I didn't quite grok prior conversations about this protocol.
It seems like your mindset is tuned to fighting against bad
screensaving policies in a compositor, while Bryce's goal with the
extension is to allow implementing proper and good screensaving policies
*in the first place*, so that no fighting is needed.
We want the compositor to behave correctly, not offer tools to override
the compositor behaviour. Bugs should be fixed at their source, not
worked around at every other place.
I hear you. Not fighting, per se, but rather 'temporarily override'.
I'm just stating that an application should be able to inhibit idling:

a) On all outputs
b) Whether it is visible or not

Per the use case I described above. Whether it uses this inhibitor protocol
or some other API is fine. But if such a use case /should/ use the inhibitor
protocol, then the per-output constraint and visibility constraint in the
protocol would make this functionality 'impossible'.

yong
Post by Pekka Paalanen
Thanks,
pq
Bryce Harrington
2016-06-06 19:11:57 UTC
Permalink
Post by Yong Bakos
Post by Pekka Paalanen
Post by Yong Bakos
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.'
An ordinary client must not be able to do that.
Post by Yong Bakos
There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.
If you cannot see the widget anyway, it must not be able to affect
screen saving. Therefore by definition, surfaceless clients must not be
able to inhibit.
Post by Yong Bakos
Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
It should work per-output. If there is important info on just one
output, why should the other outputs also stay on for no good reason?
Just because I'm looking at info on one monitor doesn't mean I want my other
monitors to go to sleep.
Not quite, there's actually three different situations to consider

First is if you're watching one monitor and doing something else on the
other. Like watching a movie while browsing emails. In this case, your
other usage is going to be generating input activity, and the system
isn't going to be idling to sleep in the first place, so inhibition
simply isn't relevant.

Next consider if you're passively watching two things at once, one
client on one screen and another client on the other. Maybe you're
monitoring a security camera on one screen and watching live stock
tickers on the other or something. Well, this is completely in scope of
the idle inhibit design - each client issues an idle inhibit request and
you're good to go.

Finally consider you're watching something on one and *not* doing
anything on the other. In this case, the second head *should* power
save when appropriate.

State of the art for most screensaver inhibitor tech addresses the
second situation, but leaves the third unsolved. We should be able to
handle the set.
Post by Yong Bakos
I can imagine this being specified via a shell's
screensaver/power savings config panel, with a checkbox enabling "idle per screen" or "idle
all screens in unison." So I think this is a moot point.
Exactly - in practice there are generally out-of-band ways to control
screensavers and DPMS and so forth. I'm trying to avoid making any
assumptions that they exist or are usable, but at least for cases in
where a given client hasn't implemented idle inhibition, or is broken
for some other reason, the user is going to have options. The protocol
doesn't need to design for non-supporting clients.
Post by Yong Bakos
However, I don't believe that just because a surface is occluded, that
it's ability to inhibit idling should be suppressed.
It's entirely possible; I don't claim to be prescient about all the
various use cases that may exist. But that would be a pretty
fundamental change, so lets only consider it if there are likely use
cases that just can't be addressed with what we've got so far.

Like I mentioned earlier, we've actually taken a few things *out* of the
protocol because we just lacked rational use cases for them, and because
its easy to add more functionality later but much much harder to remove
functionality that proves unnecessary later.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Yong Bakos
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
That is explicitly not what we want to enable.
What is this "caffeine" you talk about? I've never heard of it. Maybe I
never had to fight against screen saving.
http://tinyurl.com/caffeine-widget-2
OSX and others have something similar. This program visually resides in the
menubar/taskbar of the shell. It has two states, on and off. On (caffeinated)
overrides the configured screensaver/sleep idle timeout, preventing /all/
monitors from idling. In the off (un-caffeinated) state, the system behaves
according to configuration.
Use case: I've configured my system to screensave at 5 minutes and put the
monitors to sleep at 10 minutes. But sometimes, I want to override this
without going in and changing my config, only to have to change it back
later. I run the caffeine widget, turn it on, and all my monitors remain on
despite me not interacting with my machine. This behavior remains valid
even if I am running a program fullscreen, which occludes the visibility
of the widget.
It sounds like, from what Bryce had wrote in a separate reply, such a
widget would use a different API and not this idle inhibitor protocol. I
might be misunderstanding his point.
Right, idle-inhibit is a functionality that is automatic and
per-client. What you're describing here is a *manual* and *global* way
of letting the user change the screensaver settings. So like imagine in
weston this would effectively be a run-time API for setting --idle-time.

So, maybe in the same class as idle-inhibit but a totally different
functionality. I'd like to imagine idle-inhibit makes such a
functionality unnecessary, but regardless it'd be a different
discussion.

(As an aside, such a function *probably* should not be made available to
arbitrary clients since it is changing a global setting; it probably
would fall in the same category as screen reconfiguration or screen
capture and require special privileges. And as such it would almost
certainly have to be a compositor-specific thing, and thus likely
implemented over DBUS or however else the compositor handles config
setting type functionality.)
Post by Yong Bakos
Post by Pekka Paalanen
Post by Yong Bakos
Forgive me if I didn't quite grok prior conversations about this protocol.
It seems like your mindset is tuned to fighting against bad
screensaving policies in a compositor, while Bryce's goal with the
extension is to allow implementing proper and good screensaving policies
*in the first place*, so that no fighting is needed.
We want the compositor to behave correctly, not offer tools to override
the compositor behaviour. Bugs should be fixed at their source, not
worked around at every other place.
I hear you. Not fighting, per se, but rather 'temporarily override'.
a) On all outputs
b) Whether it is visible or not
Per the use case I described above. Whether it uses this inhibitor protocol
or some other API is fine. But if such a use case /should/ use the inhibitor
protocol, then the per-output constraint and visibility constraint in the
protocol would make this functionality 'impossible'.
That's a really good indication that these are two distinct
functionalities, and shouldn't be conflated together.

Bryce
Yong Bakos
2016-06-06 15:08:12 UTC
Permalink
Post by Pekka Paalanen
On Fri, 3 Jun 2016 10:39:24 -0500
Post by Yong Bakos
Hi,
Post by Pekka Paalanen
On Fri, 3 Jun 2016 09:26:24 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
you posted the last one marked as v3, so this would have been v4.
Post by Jonas Ådahl
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
Yeah, makes sense.
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
Shouldn't there be a "create" request so clients can obtain the manager object?
Hi,
that request is wl_registry.bind, as for all globals.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
destroy the idle inhibit manager
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ This destroys the inhibit manager.
Good addition. Should probably say how destroying the manager affects
the inhibitors created from it (no effect at all)?
Agreed w/ pq. But, is the inhibit manager a /singleton/ global?
Yes.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
Does it make sense to associate inhibitors to surfaces, rather than clients?
See below.
Yes, they must be associated to surfaces.
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
I don't believe this is a good choice. Imagine the case of a surface-less
'inhibitor daemon.'
An ordinary client must not be able to do that.
Post by Yong Bakos
There may be no visible surface (is my thinking out
of scope here?). Imagine another case, that of a "caffeine" widget. This
widget's surface would be hidden when another app is fullscreen.
If you cannot see the widget anyway, it must not be able to affect
screen saving. Therefore by definition, surfaceless clients must not be
able to inhibit.
Post by Yong Bakos
Furthermore, I don't believe that inhibition should be coupled to outputs.
See below.
It should work per-output. If there is important info on just one
output, why should the other outputs also stay on for no good reason?
Just because I'm looking at info on one monitor doesn't mean I want my other
monitors to go to sleep. I can imagine this being specified via a shell's
screensaver/power savings config panel, with a checkbox enabling "idle per screen" or "idle
all screens in unison." So I think this is a moot point. However, I
don't believe that just because a surface is occluded, that it's ability
to inhibit idling should be suppressed.
Post by Pekka Paalanen
Post by Yong Bakos
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
+
+ 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.
Right, I was thinking something like: Sub-surfaces that do not have an
inhibitor associated inherit the inhibition behaviour from their
parent. This applies recursively.
wl_surface A is a top-level, only on output 1.
wl_surface B is a sub-surface to A, only on output 2.
wl_surface C is a sub-surface to B, only on output 3.
wl_surface B has an inhibitor associated. All surfaces are completely
visible etc. on their own outputs.
Output 1 will go to powersave: no surface is inhibiting it.
Output 2 does not go to powersave: B inhibitor is in effect.
Output 3 does not go to powersave: C inherits B's inhibitor behaviour.
I don't believe that inhibition should /only/ be coupled to outputs.
In the case of a "caffeine" widget or daemon, the use case is to
prevent /all/ outputs from idling, regardless of what output the widget's
surface resides upon.
That is explicitly not what we want to enable.
What is this "caffeine" you talk about? I've never heard of it. Maybe I
never had to fight against screen saving.
Here's a screenshot of the Gnome-flavored implementation of the widget:
http://tinyurl.com/caffeine-widget-2

OSX and others have something similar. This program visually resides in the
menubar/taskbar of the shell. It has two states, on and off. On (caffeinated)
overrides the configured screensaver/sleep idle timeout, preventing /all/
monitors from idling. In the off (un-caffeinated) state, the system behaves
according to configuration.

Use case: I've configured my system to screensave at 5 minutes and put the
monitors to sleep at 10 minutes. But sometimes, I want to override this
without going in and changing my config, only to have to change it back
later. I run the caffeine widget, turn it on, and all my monitors remain on
despite me not interacting with my machine. This behavior remains valid
even if I am running a program fullscreen, which occludes the visibility
of the widget.

It sounds like, from what Bryce had wrote in a separate reply, such a
widget would use a different API and not this idle inhibitor protocol. I
might be misunderstanding his point.
Post by Pekka Paalanen
Post by Yong Bakos
Post by Pekka Paalanen
This raises a corner-case: If surface B becomes completely occluded so
that the compositor considers it is no longer inhibiting, what happens
with output 3? Should it powersave or not?
That is a strange use case but still possible. I'm not sure what should
happen. Should it behave like C had its own inhibitor, or should the
inheritance take also the effectiveness of the inhibitor on B?
I suppose you could pick either way.
Post by Jonas Ådahl
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
Ok, this looks quite good, just a couple clarifications would be nice.
If you agree with my "inherited from parent" idea instead of from
Thanks,
pq
Forgive me if I didn't quite grok prior conversations about this protocol.
It seems like your mindset is tuned to fighting against bad
screensaving policies in a compositor, while Bryce's goal with the
extension is to allow implementing proper and good screensaving policies
*in the first place*, so that no fighting is needed.
We want the compositor to behave correctly, not offer tools to override
the compositor behaviour. Bugs should be fixed at their source, not
worked around at every other place.
I hear you. Not fighting, per se, but rather 'temporarily override'.
I'm just stating that an application should be able to inhibit idling:

a) On all outputs
b) Whether it is visible or not

Per the use case I described above. Whether it uses this inhibitor protocol
or some other API is fine. But if such a use case /should/ use the inhibitor
protocol, then the per-output constraint and visibility constraint in the
protocol would make this functionality 'impossible'.

yong
Post by Pekka Paalanen
Thanks,
pq
Bryce Harrington
2016-06-08 02:10:25 UTC
Permalink
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
How about just a simple:

for each surface as appropriate.
Post by Jonas Ådahl
Post by Bryce Harrington
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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.

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.

Bryce
Post by Jonas Ådahl
Jonas
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
1.9.1
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Jonas Ådahl
2016-06-08 02:51:30 UTC
Permalink
Post by Bryce Harrington
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
for each surface as appropriate.
I don't think it hurts with the extra clarity as one won't have to guess
what is appropriate or not.
Post by Bryce Harrington
Post by Jonas Ådahl
Post by Bryce Harrington
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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?
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; its the job of the browser to
do this for us and create the appropriate inhibit objects. We should
only care about allowing the web browser to create those objects to get
a well defined behavior.
Post by Bryce Harrington
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.

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.


Jonas
Post by Bryce Harrington
Bryce
Post by Jonas Ådahl
Jonas
Post by Bryce Harrington
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This removes the inhibitor effect from the associated wl_surface.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
--
1.9.1
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Pekka Paalanen
2016-06-08 09:02:14 UTC
Permalink
On Wed, 8 Jun 2016 10:51:30 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
Post by Jonas Ådahl
Post by Bryce Harrington
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.
---
+ Rename protocol to idle-inhibit
+ Added a destructor for the idle manager
+ Changed sub-surface behavior to inherit idle from parent surface
+ Various wording changes suggested by pq
Hi,
I think this looks sane, I only have a couple of questions that might
need clarification.
Post by Bryce Harrington
Makefile.am | 1 +
unstable/idle-inhibit/README | 4 ++
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 84 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 unstable/idle-inhibit/README
create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 71d2632..de691db 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols = \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
+ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
new file mode 100644
index 0000000..396e871
--- /dev/null
+++ b/unstable/idle-inhibit/README
@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..af3a911
--- /dev/null
+++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+ <copyright>
+ Copyright © 2015 Samsung Electronics Co., Ltd
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_idle_inhibit_manager_v1" version="1">
+ <description summary="control behavior when display idles">
+ This interface permits inhibiting the idle behavior such as screen
+ blanking, locking, and screensaving. The client binds the idle manager
+ globally, then creates idle-inhibitor objects for each surface.
+ for each surface that should inhibit the idle behavior. ?
for each surface as appropriate.
I don't think it hurts with the extra clarity as one won't have to guess
what is appropriate or not.
Post by Bryce Harrington
Post by Jonas Ådahl
Post by Bryce Harrington
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the idle inhibitor object">
+ This destroys the inhibit manager.
+ </description>
+ </request>
+
+ <request name="create_inhibitor">
+ <description summary="create a new inhibitor object">
+ Create a new inhibitor object associated with the given surface.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface that inhibits the idle behavior"/>
+ </request>
+
+ </interface>
+
+ <interface name="zwp_idle_inhibitor_v1" version="1">
+ <description summary="context object for inhibiting idle behavior">
+ An idle inhibitor prevents the output that the associated surface is
+ visible on from being blanked, dimmed, locked, set to power save, or
+ otherwise obscured due to lack of user interaction. Any active
+ screensaver processes are also temporarily blocked from displaying.
+
+ If the surface is destroyed, unmapped, becomes occluded or otherwise
+ loses visibility, the screen behavior is restored to normal; if the
+ surface subsequently regains visibility the inhibitor takes effect once
+ again.
+
+ 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?
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; its the job of the browser to
do this for us and create the appropriate inhibit objects. We should
only care about allowing the web browser to create those objects to get
a well defined behavior.
Agreed.
Post by Jonas Ådahl
Post by Bryce Harrington
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.
Post by Jonas Ådahl
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. Would this be an
acceptable compromise?


Thanks,
pq
Bryce Harrington
2016-06-08 20:37:34 UTC
Permalink
Post by Pekka Paalanen
On Wed, 8 Jun 2016 10:51:30 +0800
Post by Jonas Ådahl
Post by Bryce Harrington
Post by Jonas Ådahl
Post by Bryce Harrington
+ 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?
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.
Post by Pekka Paalanen
Post by Jonas Ådahl
Post by Bryce Harrington
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.
Post by Pekka Paalanen
Post by Jonas Ådahl
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?
- 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.
- 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
Pekka Paalanen
2016-06-09 07:27:03 UTC
Permalink
On Wed, 8 Jun 2016 13:37:34 -0700
Post by Bryce Harrington
Post by Pekka Paalanen
- 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.
Ok, let's go your way. FWIW, Quentin agrees with you even though he
didn't want to say it on the mailing list.

I will not object ignoring sub-surfaces any longer.

The concern raised in
https://lists.freedesktop.org/archives/wayland-devel/2016-March/027667.html
is theoretical so far. You can adress them when they actually arise.


Thanks,
pq

Continue reading on narkive:
Loading...