NONE window_decorations does not work on GNOME 40 Wayland

[almereyda]

What Operating System(s) are you seeing this problem on?

Linux Wayland

WezTerm version

20210824-085333-d38ba132

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When disabling window decorations with Wayland enabled, the title bar is not hidden and displayed in an odd location.

This is because the actual terminal pane will only resize to the full window size when been having been hovered.

The post-creation resizing only works if debug mode is not active.
It will remain available as a micro terminal until touched, while the title bar will not be part of the application window in a focussed screen shot (Alt + Print):

To Reproduce

On Fedora 34 with GNOME 40 on Wayland, run wezterm with the configuration below and experience the described glitches.

Configuration

  window_decorations = "NONE",
  enable_wayland = true,

Expected Behavior

WezTerm displays itself similarly to what we see when using the configuration

  window_decorations = "NONE",
  dpi = 192.0,

through XWayland.

Logs

 2021-08-24T20:00:13.834Z INFO  wezterm_mux_server_impl::local > setting up /run/user/1000/wezterm/gui-sock-127366
 2021-08-24T20:00:14.094Z INFO  wezterm_gui::termwindow        > OpenGL initialized! Mesa Intel(R) UHD Graphics 620 (KBL GT2) 4.6 (Compatibility Profile) Mesa 21.1.7 is_context_loss_possible=false wezterm version: 20210824-085333-d38ba132

Anything else?

No response

[wez]

Note that https://wezfurlong.org/wezterm/config/lua/config/window_decorations.html states that window_decorations is not supported on Wayland.

I think the other things you describe overlap with #1020

As discussed in that other issue, I can't run Wayland on my nvidia hardware so progress on annoying issues like these is very slow: I have empathy for them, but trying to improve them is about 10x harder and more time consuming than me spending my spare time on other things.

I'd love to accept contributions from others that improve this!

[almereyda]

Thank you for the analysis. Indeed it seems hard to expect you to develop for platforms, where hardware support is not given. I am here on amdgpu and i915, if that helps.

Which would be the places in the code base to look into for improvements in this direction? I am new to the Rust ecosystem ¹ and would have to work myself from the bottom up.

As long as there is time and community interest, we could start a feature branch draft and slowly discuss the implementation in an associated PR.

[wez]

If you'd like to dive into controlling the window decorations and resize behavior, some background is probably a helpful place to start:

Under Wayland, the compositor by default abdicates responsibility for drawing window decorations, so a client typically needs to have some way to draw its own client-side decorations. There are a couple of wayland protocol "shell" extensions that allow an application to request server side decorations.

In the Rust ecosystem, the smithay-client-toolkit crate provides some assistance with abstracting over the different versions of the "shell" protocols to obtain a window surface.

That client used to provide an implementation of client-side decorations but recently deprecated and removed it. In wezterm, we have a copy of that implementation from before it was removed; it can be found in this source file:
https://github.com/wez/wezterm/blob/main/window/src/os/wayland/frame.rs

At a basic level, if you want window_decorations to work on wayland, you'll need to arrange for https://docs.rs/smithay-client-toolkit/0.15.1/smithay_client_toolkit/window/struct.Window.html#method.set_decorate to be called in the appropriate places.

This bit of code is where we first get the window object on which we could call set_decorate and apply the initial window decoration config at window creation time:

wezterm/window/src/os/wayland/window.rs

Line 290 in 45576ee

window.set_app_id(class_name.to_string());

in addition, to be able to respond to the config file hot reloading and applying the configuration, we'll need to implement the config_did_change method for the Wayland window. This is where we do this for X11:

https://github.com/wez/wezterm/blob/main/window/src/os/x11/window.rs#L872-L875

This is the impl block where the wayland config_did_change method would need to be located:

wezterm/window/src/os/wayland/window.rs

Line 925 in 45576ee

fn toggle_fullscreen(&mut self) {

I'd suggest implementing a function similar in spirit to this one in the X11 implementation:
https://github.com/wez/wezterm/blob/main/window/src/os/x11/window.rs#L606
where it translates the wezterm WindowDecorations value into the client toolkit https://docs.rs/smithay-client-toolkit/0.15.1/smithay_client_toolkit/window/enum.Decorations.html value and calls https://docs.rs/smithay-client-toolkit/0.15.1/smithay_client_toolkit/window/struct.Window.html#method.set_decorate

Maybe that is all that is needed, but I wouldn't be surprised if there were some additional changes needed in https://github.com/wez/wezterm/blob/main/window/src/os/wayland/frame.rs to respect the configured decorations.

[almereyda]

Thank you @wez for the detailed explanation. This is exactly why I was asking.

Please allow some time to pass, before a voluntary contribution can come into existence here. Yet this sounds like a fun thing to explore, when rainy and dark autumn days arrive.

[EpocSquadron]

@wez it's also worth noting that there is a separate library that popped up recently to provide client side decorations under wayland. I don't see any bindings for rust yet, and i don't know if smithay would have to pull it in or if wezterm could use it on the side, but I figure it's worth a peek.

[wez]

I saw libdecor, but it seems like it is a distinctly limited subset of the frame drawing we inherited from SCTK. I don't see there being any value in targeting libdecor in wezterm.

[valpackett]

the actual terminal pane will only resize to the full window size when been having been hovered.

Oh. This is a scaling issue I've just encountered as #1111 and fixed as #1112. Could not find this report because it mentioned nothing about HiDPI.

I can't run Wayland on my nvidia hardware

You don't have to run directly on hardware, you can run most compositors nested in a window (on X11). At least wlroots ones (Wayfire, sway, …) and weston.

used to provide an implementation of client-side decorations but recently deprecated and removed it

Actually they still have FallbackFrame, which I think is what winit still uses.

I don't see there being any value in targeting libdecor in wezterm.

Well, it seems like the eventual goal of libdecor is to have desktop environments provide libdecor plugins so any apps using libdecor could achieve that DE-native look…?

---

just stumbled upon these lines https://github.com/rust-windowing/winit/blob/1b3b82a3c1369c5248a2e6a251230ba6c615e918/src/platform_impl/linux/wayland/window/mod.rs#L226-L230 I wonder if they could be relevant to anything

[wez]

I can't run Wayland on my nvidia hardware
You don't have to run directly on hardware, you can run most compositors nested in a window (on X11). At least wlroots ones (Wayfire, sway, …) and weston.

I've tried those, but running that way is not the same as running the compositor directly; the behavior is subtly different and each of them is differently magical :-/

Actually they still have FallbackFrame, which I think is what winit still uses.

It is, but it doesn't have the ability to render text in the title bar, so we have those bits and connect them to our font rasterizer.
It's still far from perfect!

Well, it seems like the eventual goal of libdecor is to have desktop environments provide libdecor plugins so any apps using libdecor could achieve that DE-native look…?

At that point it will become more interesting, but it still seems pretty bare bones today!

[wez]

I believe that the commit that I just pushed resolves this; please give it a try and let me know! It can take up to 30 minutes for a commit to show up in a nightly binary download.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.