Add inhibit_fullscreen command

[kennylevinsen]

Some clients have special UIs in fullscreen mode, commonly optimized for no-fuss content delivery. Examples of such applications would be browsers playing videos. In such cases, the fullscreen UI is often only the video (potentially with overlays), making video consumption much more comfortable. Other applications may remove menu bars or other interfering elements.

However, one may simply wish to consume the fullscreen UI, not actually fullscreen the application. This is especially true for a tiling window manager, where one may have dedicated a fixed amount of screen real estate for the application. For a video, one could for example dedicate the area for the aspect ratio, leaving what would otherwise be black borders open to other work.

This PR implements a fullscreen inhibition feature in sway. When inhibited, sway will answer fullscreen requests correctly, but will not fullscreen the container.

[kennylevinsen]

Pending implementation of a command to toggle this.

[kennylevinsen]

There is an interesting corner case right now if you do as follows:

• Fullscreen a video in firefox on youtube
• Inhibit fullscreen
• Un-fullscreen, which does not unfullscreen the container due to inhibition
• Uninhibit fullscreen
• Now, fullscreening the video will not do anything, but f11 will work to unfullscreen.

Other than that, this seems to work quite nicely.

[pedrocr]

This is awesome. Thanks again for implementing this, and for doing it so quickly. Arranging a bunch of youtube videos in a grid became really pleasant. I can now have just the video playing and if I want to actually fullscreen one of them I can navigate to it and do $mod+f.

[RedSoxFan]

i3 discussion: i3/i3#1227

I think this is in the same boat as fullscreen transparency, where it may be useful/desirable, but is a xdg-shell protocol violation. I think the relevant portion for this is:

If the surface doesn't cover the whole output, the compositor will position the surface in the center of the output and compensate with border fill covering the rest of the output

I'll provide my comments on the implementation itself in case the others disagree. I'm not a huge fan of having both fullscreen_mode and is_fullscreen (which is never actually accessed). I think a new fullscreen mode (FULLSCREEN_VIEW?) might be better. There are also a few cases that would also need to be handled:

• The case mentioned above
  • I think inhibiting a view that is fullscreen, should change it to FULLSCREEN_VIEW
  • Likewise, removing an inhibitor from a view that is FULLSCREEN_VIEW should restore/set the requested fullscreen mode
• User executed fullscreen commands should not bypass the inhibitor
  • Instead the inhibitor should be disabled and re-enabled
  • Executing the fullscreen commands should switch between the view thinking it is fullscreen
• An ancestor's fullscreen status should not remove the fullscreen status of the inhibited view

[pedrocr]

As I'm a very happy user of this let me give my view on the two issues. First the question if this should exist at all. It is indeed the exact same discussion as in i3. I think this is very useful and makes sense because there's no reason for the app to know the difference between being in a window and being fullscreen at the same size. I don't see a protocol violation unless it's part of the API that the app can then use the total screen dimensions to make assumptions about it's buffer. The information that this was done leaks that way and for example the current Youtube UI uses it to give a dismissable warning that something strange happened, but still work correctly. Other than that information leakage there's no reason for an app to not react properly to resize events during fullscreen as that also happens on being changed to another output.

As for your implementation suggestion, that's how the original version worked, and the current one is much better. If you treat this as another fullscreen state then you don't get one of the major benefits of the current patch which is to be able to make a window fullscreen and back while the app continues with its fullscreen UI. This is very useful when you have a mosaic of video streams and then want to focus on a single one for a bit. I used that to great effect to follow Le Mans this year:

Using the previous patch (the method you suggest) meant that every time I went actual fullscreen with one of the streams when I came out of fullscreen the app UI would come out of the fullscreen mode. With this mode everything was seamless. All the streams are fullscreen from the point of view of the browser window and stay that way. Doing fullscreen on/off in sway just creates a resize event while fullscreen which is something all apps already have to support.

The only alternative to get the same behavior is to patch every app to be able to not send fullscreen events at all. Firefox has a way to do that globally with an about:config setting for example which is much inferior to deciding that per window. Doing it centrally in sway makes things much more consistent. I have a keybinding that does this and it works for everything (e.g., VMs, video apps, etc).

[RedSoxFan]

Before I comment further, I just want to clarify that I'm in favor of the feature, but I don't want to approve a protocol violation or code that feels more like a hack than a fully fleshed out feature.

I don't see a protocol violation

I outlined where the violation was in my previous comment. However, there was some discussion on IRC and it looks like ddevault is going to try to get the protocol changed to give the compositor more control/flexibility. The current version of the proposed change is https://paste.sr.ht/%7Esircmpwn/f5e54de82418a202eef9193efe9f1c7fecb9cc8e

that's how the original version worked,

I didn't look at the original commit for this PR previously, but it was only a partial implementation of what I proposed above. Fully fleshing that version out would be the better implementation in my opinion.

If you treat this as another fullscreen state then you don't get one of the major benefits of the current patch which is to be able to make a window fullscreen and back while the app continues with its fullscreen UI.

My proposed implementation would allow the user to toggle the inhibitor, which would toggle the view between FULLSCREEN_VIEW and FULLSCREEN_WORKSPACE (or FULLSCREEN_GLOBAL).

[pedrocr]

I outlined where the violation was in my previous comment. However, there was some discussion on IRC and it looks like ddevault is going to try to get the protocol changed to give the compositor more control/flexibility.

I saw that but didn't realize the protocol violation was not reacting visually in that way to the same sequence of events. The actual fullscreen/resize events are being handled in a compatible way. But I see now that the protocol definition also includes the actual visual interpretation of the wire protocol.

My proposed implementation would allow the user to toggle the inhibitor, which would toggle the view between FULLSCREEN_VIEW and FULLSCREEN_WORKSPACE (or FULLSCREEN_GLOBAL).

The current solution is encoding 4 different states which I'm not following how they would map to your proposal. Once you've made a FULLSCREEN_VIEW to FULLSCREEN_WORKSPACE change with $mod+f how do you know with the next $mod+f to go back to FULLSCREEN_VIEW instead of FULLSCREEN_NONE? Your proposal says "Executing the fullscreen commands should switch between the view thinking it is fullscreen" so I assume I would need to do a more complex sequence of key presses, essentially pushing the state management to the user.

[RedSoxFan]

The current solution is encoding 4 different states which I'm not following how they would map to your proposal

• If the view is not inhibited, the view can be FULLSCREEN_NONE, FULLSCREEN_WORKSPACE, or FULLSCREEN_GLOBAL.
• If the view is inhibited, the view can be FULLSCREEN_NONE or FULLSCREEN_VIEW.
  • When the view is set to fullscreen, the desired mode (either FULLSCREEN_WORKSPACE or FULLSCREEN_GLOBAL) is stored, but FULLSCREEN_VIEW is used
• The fullscreen commands should toggle between the FULLSCREEN_NONE and the appropriate fullscreen mode
• Enabling an inhibitor for a view that is FULLSCREEN_WORKSPACE or FULLSCREEN_GLOBAL should store the mode and switch to FULLSCREEN_VIEW.
• Disabling an inhibitor for a view that is FULLSCREEN_VIEW should switch to the stored fullscreen mode (either FULLSCREEN_WORKSPACE or FULLSCREEN_GLOBAL).

So I assume I would need to do a more complex sequence of key presses, essentially pushing the state management to the user.

The fullscreen commands would change the fullscreen status of the view. The inhibitor changes which fullscreen modes are allowed.

[pedrocr]

Got it now, thanks. You're encoding what was previously two different states all in the same state machine. From the point of view of the user the result is the same so it's an implementation decision.

[kennylevinsen]

Before I comment further, I just want to clarify that I'm in favor of the feature, but I don't want to approve a protocol violation or code that feels more like a hack than a fully fleshed out feature.

You should absolutely not approve hacks! We should see the outcome of the new discussion on wayland-devel, and we should shape this how we want it to behave rather than merge and end up with annoying legacy features.

Model

The previous implementation used an additional fullscreen mode, FULLSCREEN_FAKE. This was made to work somewhat, but ended up much more complicated. Some places assume fullscreen_mode != 0 means "covers entire output". The implementation now in place was instead chosen to be simpler, as it is entirely orthogonal to fullscreen management.

However, I am open to revisiting this behavior.

Inhibiting user fullscreen and restoring mode

I don't necessarily see this as optimal/practical. It also seems a bit more hacky to me when you consider that other fullscreen modes can be explicitly requested (i.e. global). Having it be a fullscreen mode, but on uninhibit jump back to another fullscreen mode also seems a bit magic to me. This is of course a matter of preference.

However, idea: What if we made it a fully exposed fullscreen mode, and instead made a setting for the default fullscreen mode? This would be exposed as two commands: fullscreen [workspace|global|view], and default_fullscreen [workspace|global|view]. fullscreen without parameter, as well as fullscreen requests from clients would both follow the default_fullscreen behavior. default_fullscreen could optionally also have a flag for whether it should be container or global. It could potentially also have flags to distinguish between client and user requests, i.e. default_fullscreen for global from client view to always "inhibit" client requests.

I feel like this approach would be much cleaner. What do you think?

[RedSoxFan]

We should see the outcome of the new discussion on wayland-devel

Just for reference, the thread can be found at https://lists.freedesktop.org/archives/wayland-devel/2019-June/040636.html

However, idea: What if we made it a fully exposed fullscreen mode, and instead made a setting for the default fullscreen mode? This would be exposed as two commands

This approach sounds fine to me.

[pedrocr]

I took a stab at implementing default_fullscreen [view|workspace|global]:

swaywm:d0d0181...pedrocr:87d2484

I left the fullscreen command syntax unchanged but when in FULLSCREEN_VIEW it will change to FULLSCREEN_WORKSPACE or FULLSCREEN_GLOBAL as requested.

This mostly works but I don't like it for two reasons:

• After getting a youtube window FULLSCREEN_VIEW, you can get it actually fullscreen just fine. But once you come out of that mode you go back to FULLSCREEN_NONE and youtube goes out of its fullscreen UI. This is unavoidable because FULLSCREEN_WORKSPACE doesn't know it's coming from a previously FULLSCREEN_VIEW mode.
• Doing default_mode view then doesn't allow you to do default_mode global to get a window with fullscreen UI and that when you do fullscreen it will end up as FULLSCREEN_GLOBAL.

The reason for both issues is that this shoe-horns two different features into the same state:

• default_fullscreen view is the inhibit_fullscreen replacement that signals that this window should not actually be displayed fullscreen if the app requests it.
• default_fullscreen global is the setting for which fullscreen mode this client should use as default when that's not specified in the fullscreen command.

Better semantics might be:

• fullscreen_decouple_client [enable|disable|toggle]: when active fullscreen events to/from the app are suppressed/ignored. Just a renamed version of the current inhibit_fullscreen but describing what it actually does.
• default_fullscreen [workspace|global]: just a convenience that sets which mode will be used if a fullscreen event comes from an app or from a fullscreen command without arguments.

[kennylevinsen]

I left the fullscreen command syntax unchanged but when in FULLSCREEN_VIEW it will change to FULLSCREEN_WORKSPACE or FULLSCREEN_GLOBAL as requested.

One of the key aspects of this implementation is the presence of fullscreen [view|workspace|global]. It will feel like a worse version of inhibit_fullscreen without.

This mostly works but I don't like it for two reasons:

• After getting a youtube window FULLSCREEN_VIEW, you can get it actually fullscreen just fine. But once you come out of that mode you go back to FULLSCREEN_NONE and youtube goes out of its fullscreen UI. This is unavoidable because FULLSCREEN_WORKSPACE doesn't know it's coming from a previously FULLSCREEN_VIEW mode.

This is the job of fullscreen view. You can freely move between fullscreen modes without the application caring. The applications do not care about extra fullscreen events. I do see how this can have slightly better UX in the FULLSCREEN_VIEW suggestion, though.

• Doing default_mode view then doesn't allow you to do default_mode global to get a window with fullscreen UI and that when you do fullscreen it will end up as FULLSCREEN_GLOBAL.

While I don't really understand your explanation about default_fullscreen, you do have a point with something not handled by FULLSCREEN_VIEW that was handled by inhibit_fullscreen: To have a view fullscreened in any size without informing the client, thus forcing it to keep its UI intact.

While I have yet to find a need for this (and at the same time also like to avoid over-engineering for scenarios that will never occur), it is a very valid point that we should consider.

Current implementation suggestions

1. A fullscreen mode (FULLSCREEN_VIEW), fully exposed to the user as fullscreen [view|workspace|global].

   • Upsides:
     • Logically simple.
     • Direct paths to any fullscreen mode from any point (although clients may have multiple fullscreen buttons that do different things, such as a video fullscreener vs. window fullscreener).
   • Downsides:
     • Does not allow non-fullscreen UI taking up whole output/all outputs.
     • Each fullscreen mode is its own command rather than a toggle.
   • Primary uses:
     • fullscreen view for applications which do the right thing (TM), or
     • Click client fullscreen (which defaults to workspace), then fullscreen view to constrain it, or
     • Set default_fullscreen view so clients always use that mode, and fullscreen workspace when you want true fullscreen (what I would do).

2. A decoupling feature that makes it so sway container fullscreen and client fullscreen does not affect each other, as done by inhibit_fullscreen.

   • Upsides:
     • Single-command toggle between workspace and view fullscreen without changing the client state while inhibition is in effect (just fullscreen)
     • Less code (although not necessarily prettier code).
   • Downsides:
     • No direct path to constrained fullscreen: One must first inhibit, then use a client method to enter.
     • More complicated concept.
     • Potentially to be seen as more of a lie on the protocol.
   • Primary uses:
     • inhibit_fullscreen for a container just before using the client fullscreen feature, or
     • inhibit_fullscreen just before issuing fullscreen if the inverse mode is wanted.

@RedSoxFan 's comments to inhibit_fullscreen makes it work mostly as solution number one, so in that case I would prefer that as a purer solution. Number two is basically the original implementation.

[pedrocr]

One of the key aspects of this implementation is the presence of fullscreen [view|workspace|global]. It will feel like a worse version of inhibit_fullscreen without.

Those can be also added. But I guess you're also suggesting fullscreen toggles between FULLSCREEN_NONE and FULLSCREEN_VIEW. That's an annoying UX where after default_fullscreen view you need another binding to make a window FULLSCREEN_WORKSPACE.

But if that's done then I don't see the value of default_fullscreen. Might as well just have fullscreen [enable|disable|toggle] [view|workspace|global] and make the user bind the ones he wants to use. default_fullscreen ends up only being a way to transform the app's fullscreen on/off into none|view|workspace|global which will never be a full mapping.

While I don't really understand your explanation about default_fullscreen

If fullscreen no longer does FULLSCREEN_VIEW->FULLSCREEN_WORKSPACE then my point no longer applies. What I mean is that a better UX is being able to say "this window does not obey app fullscreen commands and when the user calls fullscreen we toggle to global|workspace". Having a single default_fullscreen view|workspace|global doesn't allow that.

As for the options I still prefer method 2. Considering the downsides:

No direct path to constrained fullscreen: One must first inhibit, then use a client method to enter.

I don't think this is a big issue but it would be simple to add convenience functions that do both actions together.

More complicated concept.

I think the opposite. Decoupling is a well defined concept, there are now two states that are no longer synchronized:

• On the app side with fullscreen UI on/off. This is manipulated in app and changes the app UI only.
• On sway side deciding to display the client as a window or as fullscreen workspace|global. This is manipulated in sway and changes the sway window organization only.

The FULLSCREEN_VIEW concept introduces an extra complexity where the app only knows about on/off but sway knows about none/view/workspace/global. And then those are forced to be synchronized even though as you noted the state where the app is not in fullscreen UI but sway displays fullscreen is valid. I can see myself using that to sometimes get a fullscreen firefox window where the tabs don't auto-disappear without going spelunking in about:config.

Potentially to be seen as more of a lie on the protocol.

In a sense it's actually fairer. It's basically adding a flag to disable support for that bit of the protocol. Instead of lying on what it does with the information sway is just not implementing the fullscreen protocol at all for that client at the request of the user.

[kennylevinsen]

But if that's done then I don't see the value of default_fullscreen.

It defines what happens when a client requests fullscreen, or when the user simply issues fullscreen without further specification (which must be supported for backwards/i3 compatibility).

I think the opposite. Decoupling is a well defined concept, there are now two states that are no longer synchronized:

It is simple to us, as we know of the fullscreen protocol. I am referring to an average user, who might not be aware of xdg_shell.request_fullscreen and its appropriate configure responses.

To the average user (who is not supposed to know much about wayland protocols!), fullscreen means fullscreen. I believe it is easier to explain "There are 3 different fullscreen modes, stay in container, cover entire screen, or cover all screens" than "There are two fullscreen modes, as well as a synchronization toggle for the client fullscreen protocol".

The FULLSCREEN_VIEW concept introduces an extra complexity where the app only knows about on/off but sway knows about none/view/workspace/global.

It actually does not: Sway already have workspace and global fullscreen modes. Two options that the client knows nothing of becomes three.

I can see myself using that to sometimes get a fullscreen firefox window where the tabs don't auto-disappear without going spelunking in about:config.

The primary feature here applies to many applications (anything playing video tends to have this "minimal UI only in fullscreen" behavior), so it has strong merit. I'd like to see if there is also strong merit for its inverse (i.e. more than just a potential convenience only in Firefox where an existing button is just inconveniently placed).

In a sense it's actually fairer. It's basically adding a flag to disable support for that bit of the protocol. Instead of lying on what it does with the information sway is just not implementing the fullscreen protocol at all for that client at the request of the user.

I find it a bit less of a lie if we treat it and expose it as a fullscreen mode. We entered fullscreen, it's just not very full. In the other feature, we have a switch that will respond to fullscreen requests with a "Sure, I'll fullscreen you!", without changing any state at all.

It's pedantic, sure, but I listed it regardless as pro/con.

That aside, I personally do enjoy the UX of the original implementation. I think what I intend to do is to polish that up, and then create the alternative implementation as well. We can then simply do some testing of either.

[pedrocr]

To the average user (who is not supposed to know much about wayland protocols!), fullscreen means fullscreen. I believe it is easier to explain "There are 3 different fullscreen modes, stay in container, cover entire screen, or cover all screens" than "There are two fullscreen modes, as well as a synchronization toggle for the client fullscreen protocol".

While I think this is true for the explanation of what feature is the UX will then be worse, so explaining how the feature works is harder. You pretty much have to bind extra keys to fullscreen view and fullscreen workspace beyond the key you already have for just fullscreen to be able to use this. And then for those windows in particular the muscle memory will betray you.

That aside, I personally do enjoy the UX of the original implementation.

This has been my impression from trying both as well. Once inhibit_fullscreen has been called the fullscreen on/off just works normally. And is also consistent with apps like virt-manager that don't react to fullscreen events from sway and thus already have this behavior once you enter the fullscreen UI.

I think what I intend to do is to polish that up, and then create the alternative implementation as well. We can then simply do some testing of either.

Thanks again for taking an interest in this and doing so much work. See the branch I linked for a start on the alternative implementation. I had a look at what's still missing and beyond the simple UI tweaks in the fullscreen command there's some complexity to be handled in managing all the possible state changes between fullscreen modes.

[emersion]

Note: Firefox has full-screen-api.ignore-widgets to keep the regular UI elements in fullscreen mode.

[kennylevinsen]

Additional corrective note: browser.fullscreen.autohide makes UI elements not automatically hide in fullscreen mode, full-screen-api.ignore-widgets stops the browser from requesting fullscreen mode from the compositor.

[pedrocr]

Firefox can be configured to do this globally, and maybe an extension exists or can be written to make that per-window. But this is useful for more situations. I use it for virt-manager for example, and use matching rules to apply this to specific Firefox and other windows automatically. It's really useful and has worked flawlessly for months now.

[rwanyoike]

I use this effect often with xwayland windows (eg. chromium): get the xwayland window to fullscreen itself (eg. video playing), then un-fullscreen on sway (eg. Mod+F), and manipulate the xwayland window - which remains fullscreen within - as normal. I'd like to see this possible with xdg_shell/wayland windows (eg. firefox)

[pedrocr]

I continue to use this daily. One thing I've noticed recently is that it doesn't work for XWayland windows. Chrome will still go fullscreen on F11 even if inhibit_fullscreen has been done.

[cyberhuman]

I started using this patch and it's really helpful! What I'm missing a bit is the fullscreen enable view command that was mentioned earlier.

[WhyNotHugo]

I understand this PR will allow me to make a window think it's fullscreen without it being fulscreen.

Will it also me to actually fullscreen a window without telling it it's fullscreen (e.g.: make it as big as the entire screen, but don't send it the "you are now fullscreen" signal)?

If so, I think this might cover #5397, since that's basically the definition of "maximisation".

---

I can't comment much on protocol or code, but I do think this is essentially two states:

1. Whether a window thinks its fullscreen.
2. Whether a window is being rendered fullscreen.

The current command basically toggles both attributes at once and keeps them aligned, while this PR would allow toggling one without the other. If there were a command to individually toggle either of these flag, I think that'd likely cover all potential use cases of this feature.

[pedrocr]

Will it also me to actually fullscreen a window without telling it it's fullscreen (e.g.: make it as big as the entire screen, but don't send it the "you are now fullscreen" signal)?

It does exactly that. If inhibit_fullscreen is set the fullscreen on/off state of the app and of sway gets disconnected. So setting fullscreen in sway still works, but from the point of view of the application it's just a resize.

[adlainewson]

Love this i3 "feature," hope it makes it to sway.

[arbitrary-dev]

Actually it'd be nice to have this implemented as in Awesome WM, instead of having a separate configuration setting.

There they have the following:

1. When you fullscreen the app – the container FS'ed as well
2. When the app is restored back – the container follows
3. But when you change the FS status on the container – the app stays in its current layout

[Hippo0o]

for those like me who want back their old i3 fullscreen behavior for wayland windows can use my patch i created from the v1.7 branch for now

[bim9262]

for those like me who want back their old i3 fullscreen behavior for wayland windows can use my patch i created from the v1.7 branch for now

And for those who want to install it on arch you can install sway-i3-style-fullscreen-git from AUR.

[zampierilucas]

Since this is not getting merged, is there an alternative from having to build sway with this patch?

[ogabriel]

thanks @Hippo0o and @bim9262

The AUR package works perfectly! I was almost going back to i3 because sway didnt behave like i3 on fullscreen

And for those that were not using sway-git and wlroots-git for AUR, you have to uninstall sway and swaybg before installing sway-i3-style-fullscreen-git, otherwise some dependencies problems with sway and wlroots will arise:

removing wlroots breaks dependency 'libwlroots.so' required by sway

so you have to do:

sudo pacman -R sway swaybg
# and then
yay -S sway-i3-style-fullscreen-git

[omeid]

Since this is not getting merged, is there an alternative from having to build sway with this patch?

Can we get the official word on whatever this will be merged or not? I suppose an open PR means it is still up for consideration?

This is very useful and Quality Of Life feature for a TWM. on par with Maximising for other WMs. It would be a shame if it is never going to land in the official releases.

[kennylevinsen]

Can we get the official word on whatever this will be merged or not?

There are no plans to merge this feature at this time.

[mathix420]

swayfx-i3-style-fullscreen is now broken for a while and doesn't seems to get any new update. I've created a new version if anyone ever needs it https://aur.archlinux.org/packages/swayfx-i3-style-fullscreen-2-git

[RoadRoller01]

so why there is no plans to marge this feature?