[PATCH] xdg-shell: remove constraints for fullscreen

[Jasper St. Pierre]

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190621/23b655a0/attachment.html>