xdg-shell: remove constraints for fullscreen

Submitted by Drew DeVault on June 19, 2019, 5:35 p.m.

Details

Message ID 20190619173541.7797-1-sir@cmpwn.com
State New
Headers show
Series "xdg-shell: remove constraints for fullscreen" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault June 19, 2019, 5:35 p.m.
Compositors are free to render surfaces at their discretion. This
change clarifies that for xdg-shell's fullscreen surfaces.
---
This point has been a recurring cause for frustration in Sway
development, as users expect windows beneath transparent fullscreen
windows to be shown. The main use-case for this, for example, is working
in a transparent full-screen terminal while referencing docs in a web
browser underneath. We hit this again for a different reason when
discussing a patch which would allow the user to arrange fullscreen
windows in a manner other than by using the entire screen.

At least one other compositor in the wild (Wayfire) is also not
respecting these constraints. It is my intent to loosen this restriction
and start considering sway patches which change the behavior of
fullscreen in a manner inconsistent with these constraints.

Since it's the compositors privilege to do anything it wants with
client surfaces, this updates the protocol text to reflect that, while
still suggesting the desired behavior.

 stable/xdg-shell/xdg-shell.xml | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

Patch hide | download patch | download mbox

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 2e420c6..22ff93d 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -926,16 +926,14 @@ 
 	it's up to the compositor to choose which display will be used to map
 	this surface.
 
-	If the surface doesn't cover the whole output, the compositor will
-	position the surface in the center of the output and compensate with
-	with border fill covering the rest of the output. The content of the
-	border fill is undefined, but should be assumed to be in some way that
-	attempts to blend into the surrounding area (e.g. solid black).
-
-	If the fullscreened surface is not opaque, the compositor must make
-	sure that other screen content not part of the same surface tree (made
-	up of subsurfaces, popups or similarly coupled surfaces) are not
-	visible below the fullscreened surface.
+	The compositor should interpret this as a suggestion that the fullscreened
+	surface should be shown across the entire output, however, the specific
+	position and sizing of the client on-screen is undefined. When the
+	aspect ratio of the fullscreened surface is not equal to the aspect
+	ratio of the space allocated for its display, the compositor should fill
+	the remaining space in with a neutral background (e.g. solid black). If
+	the surface is not opaque, the content (e.g. other surfaces) shown below
+	the fullscreened surface is undefined.
       </description>
       <arg name="output" type="object" interface="wl_output" allow-null="true"/>
     </request>

Comments

On Wed, Jun 19, 2019 at 01:35:42PM -0400, Drew DeVault wrote:
> Compositors are free to render surfaces at their discretion. This
> change clarifies that for xdg-shell's fullscreen surfaces.
> ---
> This point has been a recurring cause for frustration in Sway
> development, as users expect windows beneath transparent fullscreen
> windows to be shown. The main use-case for this, for example, is working
> in a transparent full-screen terminal while referencing docs in a web
> browser underneath. We hit this again for a different reason when
> discussing a patch which would allow the user to arrange fullscreen
> windows in a manner other than by using the entire screen.
> 
> At least one other compositor in the wild (Wayfire) is also not
> respecting these constraints. It is my intent to loosen this restriction
> and start considering sway patches which change the behavior of
> fullscreen in a manner inconsistent with these constraints.
> 
> Since it's the compositors privilege to do anything it wants with
> client surfaces, this updates the protocol text to reflect that, while
> still suggesting the desired behavior.
> 
>  stable/xdg-shell/xdg-shell.xml | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index 2e420c6..22ff93d 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -926,16 +926,14 @@
>  	it's up to the compositor to choose which display will be used to map
>  	this surface.
>  
> -	If the surface doesn't cover the whole output, the compositor will
> -	position the surface in the center of the output and compensate with
> -	with border fill covering the rest of the output. The content of the
> -	border fill is undefined, but should be assumed to be in some way that
> -	attempts to blend into the surrounding area (e.g. solid black).
> -
> -	If the fullscreened surface is not opaque, the compositor must make
> -	sure that other screen content not part of the same surface tree (made
> -	up of subsurfaces, popups or similarly coupled surfaces) are not
> -	visible below the fullscreened surface.
> +	The compositor should interpret this as a suggestion that the fullscreened
> +	surface should be shown across the entire output, however, the specific
> +	position and sizing of the client on-screen is undefined. When the
> +	aspect ratio of the fullscreened surface is not equal to the aspect
> +	ratio of the space allocated for its display, the compositor should fill
> +	the remaining space in with a neutral background (e.g. solid black). If
> +	the surface is not opaque, the content (e.g. other surfaces) shown below
> +	the fullscreened surface is undefined.

This changes the semantics in a non-backward compatible way; clients
relying on the currently defined behavior would break, so I'll have to
nack this change. You'd have to add a `set_fullscreen_translucent` or
something like that if the described behavior is needed.


Jonas

>        </description>
>        <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>      </request>
> -- 
> 2.22.0
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> This changes the semantics in a non-backward compatible way; clients
> relying on the currently defined behavior would break, so I'll have to
> nack this change. You'd have to add a `set_fullscreen_translucent` or
> something like that if the described behavior is needed.

To re-use an argument that was brought up in the xdg-decoration
discussion: compositors are just going to do whatever they want here,
and this sets up expectations accordingly. Wayfire already disregards
this clause, and consider this an announcement of Sway's intentions do
to the same.

In any case, I don't think this grossly affects the behavior clients
have come to rely on. I sought some feedback on this patch privately
before posting it to consider these concerns upfront. The main use-case
for the original wording was found to be media players which rely on
this behavior for letterboxing when the aspect ratio between the output
and the video differs - which is addressed in the proposed wording.

Additionally, the original wording never made any promises as to the
relationship between the fullscreened surface and the output its shown
on. One notable example is that the unreliability of wl_output's
width/height specifications forces (correctly so) users to continue to
use configure events to communicate the desired size. This is especially
necessary with non-traditional outputs like VR headsets. Implementation
details like direct scan-out, which is only possible given the
constraints in the original wording, aren't actually guaranteed - but
are not ruled out by the new wording.

What do you think? Does that rationale make more sense?
Hi,

Some compositors and client toolkits do rely on the existing wording. Occlusion culling is used for (obvious) performance reasons in fullscreen cases. If the fullscreen surface is not opaque, clients can still rely on the compositor's handling of fullscreen states using the current wording and prioritize resources for this fullscreen surface even if there are other surfaces which are visible behind it. This is especially true for embedded cases.

Given that releases and products have already shipped that rely on this language, and that the terminology and language used here is a core functionality of the feature, it absolutely cannot be changed.


Regards,
Mike

On Fri, 21 Jun 2019 14:32:34 -0400
"Drew DeVault" <sir@cmpwn.com> wrote:

> On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> > This changes the semantics in a non-backward compatible way; clients
> > relying on the currently defined behavior would break, so I'll have to
> > nack this change. You'd have to add a `set_fullscreen_translucent` or
> > something like that if the described behavior is needed.  
> 
> To re-use an argument that was brought up in the xdg-decoration
> discussion: compositors are just going to do whatever they want here,
> and this sets up expectations accordingly. Wayfire already disregards
> this clause, and consider this an announcement of Sway's intentions do
> to the same.
> 
> In any case, I don't think this grossly affects the behavior clients
> have come to rely on. I sought some feedback on this patch privately
> before posting it to consider these concerns upfront. The main use-case
> for the original wording was found to be media players which rely on
> this behavior for letterboxing when the aspect ratio between the output
> and the video differs - which is addressed in the proposed wording.
> 
> Additionally, the original wording never made any promises as to the
> relationship between the fullscreened surface and the output its shown
> on. One notable example is that the unreliability of wl_output's
> width/height specifications forces (correctly so) users to continue to
> use configure events to communicate the desired size. This is especially
> necessary with non-traditional outputs like VR headsets. Implementation
> details like direct scan-out, which is only possible given the
> constraints in the original wording, aren't actually guaranteed - but
> are not ruled out by the new wording.
> 
> What do you think? Does that rationale make more sense?
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> To be clear, the patch does break backwards compatibility with compositor
> behavior -- it only weakens a guarantee by saying that transparent
> fullscreen content is undefined. Existing compositor behavior is still
> allowed.

To weaken the guarantees previously defined is breaking backward
compatibility. Clients that implemented its functionality given the
promises defined by the specification would have to change according to
the new promises.

> 
> However, it does mean that clients might not get the output they desire
> under new rules. It also does not make any new guarantees for a client -- a
> fullscreen transparent terminal might show surfaces underneath, or it might
> not. That hardly seems useful to me from a client perspective.
> 
> That said, adding a new request does not seem like a good solution to me --
> if the user presses a compositor key shortcut, should the app be in
> transparent or opaque fullscreen mode? It might make sense to have a
> special "set_fullscreen_blend_mode" that clients can use to configure their
> fullscreen appearance in all cases. I do not imagine this will change
> often, so it likely does not need to be a state.

Setting a fullscreen blend mode as part of configuring the fullscreen
state seems more sane than a separate fullscreen request indeed.
Probably want to enforce the configured size for non-opaque blend modes
too, to not have to let the region outside the surface be undefined.


Jonas

> 
> On Fri, Jun 21, 2019, 8:43 PM Michael Blumenkrantz <
> michael.blumenkrantz@gmail.com> wrote:
> 
> > Hi,
> >
> > Some compositors and client toolkits do rely on the existing wording.
> > Occlusion culling is used for (obvious) performance reasons in fullscreen
> > cases. If the fullscreen surface is not opaque, clients can still rely on
> > the compositor's handling of fullscreen states using the current wording
> > and prioritize resources for this fullscreen surface even if there are
> > other surfaces which are visible behind it. This is especially true for
> > embedded cases.
> >
> > Given that releases and products have already shipped that rely on this
> > language, and that the terminology and language used here is a core
> > functionality of the feature, it absolutely cannot be changed.
> >
> >
> > Regards,
> > Mike
> >
> > On Fri, 21 Jun 2019 14:32:34 -0400
> > "Drew DeVault" <sir@cmpwn.com> wrote:
> >
> > > On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> > > > This changes the semantics in a non-backward compatible way; clients
> > > > relying on the currently defined behavior would break, so I'll have to
> > > > nack this change. You'd have to add a `set_fullscreen_translucent` or
> > > > something like that if the described behavior is needed.
> > >
> > > To re-use an argument that was brought up in the xdg-decoration
> > > discussion: compositors are just going to do whatever they want here,
> > > and this sets up expectations accordingly. Wayfire already disregards
> > > this clause, and consider this an announcement of Sway's intentions do
> > > to the same.
> > >
> > > In any case, I don't think this grossly affects the behavior clients
> > > have come to rely on. I sought some feedback on this patch privately
> > > before posting it to consider these concerns upfront. The main use-case
> > > for the original wording was found to be media players which rely on
> > > this behavior for letterboxing when the aspect ratio between the output
> > > and the video differs - which is addressed in the proposed wording.
> > >
> > > Additionally, the original wording never made any promises as to the
> > > relationship between the fullscreened surface and the output its shown
> > > on. One notable example is that the unreliability of wl_output's
> > > width/height specifications forces (correctly so) users to continue to
> > > use configure events to communicate the desired size. This is especially
> > > necessary with non-traditional outputs like VR headsets. Implementation
> > > details like direct scan-out, which is only possible given the
> > > constraints in the original wording, aren't actually guaranteed - but
> > > are not ruled out by the new wording.
> > >
> > > What do you think? Does that rationale make more sense?
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi,

On Mon, 24 Jun 2019 at 09:00, Jonas Ådahl <jadahl@gmail.com> wrote:
> On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> > To be clear, the patch does break backwards compatibility with compositor
> > behavior -- it only weakens a guarantee by saying that transparent
> > fullscreen content is undefined. Existing compositor behavior is still
> > allowed.
>
> To weaken the guarantees previously defined is breaking backward
> compatibility. Clients that implemented its functionality given the
> promises defined by the specification would have to change according to
> the new promises.

Yeah. I don't want to go down the road of removing promises we've made
to clients: if we absolutely must do this, then it would have to be
accompanied by a version bump so clients can opt in to the new
behaviour. But doing it without a bump means that no-one would be able
to rely on guarantees we make in protocol.

That being said ...

> > That said, adding a new request does not seem like a good solution to me --
> > if the user presses a compositor key shortcut, should the app be in
> > transparent or opaque fullscreen mode? It might make sense to have a
> > special "set_fullscreen_blend_mode" that clients can use to configure their
> > fullscreen appearance in all cases. I do not imagine this will change
> > often, so it likely does not need to be a state.
>
> Setting a fullscreen blend mode as part of configuring the fullscreen
> state seems more sane than a separate fullscreen request indeed.
> Probably want to enforce the configured size for non-opaque blend modes
> too, to not have to let the region outside the surface be undefined.

Scott wrote up a surface-blend-mode proposal a while back:
https://patchwork.freedesktop.org/patch/262025/

I wonder if we could simply specify that an explicit request for
surface blending will result in the fullscreen surface not being
pillarboxed/letterboxed with black around it?

Cheers,
Daniel