[PATCH] xdg-shell: remove constraints for fullscreen

[Jonas Ådahl]

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 at 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 at 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 at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel