Steam running in big picture mode under xwayland makes waybar disappear about labwc

[tokyo4j]

I found the problem is that the view for Big Picture Mode requests fullscreen before it's mapped.
We show or hide the top layer when a view requests fullscreen/un-fullscreen, but the view for Big Picture Mode is ignored because it's not in server->views yet for_each_view() ignores views that are not mapped.

EDIT:
Sorry, we actually inserted the view on view creation at xwayland_view_create(). I'll need to investigate more.

EDIT2:
The problem is not that the view is not in server->views, but that we check view->mapped in view_set_fullscreen() -> set_fullscreen() -> desktop_update_top_layer_visiblity() -> for_each_view() -> view_next() -> matches_criteria() -> view_is_focusable()

[tokyo4j]

This behavior is slightly annoying though, I stumble on this as well when quickly A-Tabbing away from a fullscreen window. It is difficult to solve because we can't just use fullscreen + focused as condition (you could have a panel and fullscreen video on a second monitor but work on the first monitor). So I am no quite sure how to tackle this issue.

How about showing top layer if there's any windows above fullscreen window?

hide-waybar.mp4

diff

diff --git a/src/desktop.c b/src/desktop.c
index e3feaa37..fecc2797 100644
--- a/src/desktop.c
+++ b/src/desktop.c
@@ -229,14 +229,29 @@ desktop_update_top_layer_visiblity(struct server *server)
 		wlr_scene_node_set_enabled(&output->layer_tree[top]->node, true);
 	}
 
-	/* And disable them again when there is a view in fullscreen */
+	/* And disable them again when there is a view in fullscreen without another view above it */
 	enum lab_view_criteria criteria =
 		LAB_VIEW_CRITERIA_CURRENT_WORKSPACE | LAB_VIEW_CRITERIA_FULLSCREEN;
 	for_each_view(view, &server->views, criteria) {
 		if (!output_is_usable(view->output)) {
 			continue;
 		}
-		wlr_scene_node_set_enabled(&view->output->layer_tree[top]->node, false);
+		bool another_view_above_fullscreen_view = false;
+		struct view *v;
+		for_each_view(v, &server->views,
+				LAB_VIEW_CRITERIA_CURRENT_WORKSPACE) {
+			if (v == view) {
+				break;
+			}
+			if (v->output != view->output || !view_is_focusable(v)) {
+				continue;
+			}
+			another_view_above_fullscreen_view = true;
+			break;
+		}
+		if (!another_view_above_fullscreen_view) {
+			wlr_scene_node_set_enabled(&view->output->layer_tree[top]->node, false);
+		}
 	}
 }
 
diff --git a/src/view.c b/src/view.c
index 19b5a33a..e9f30439 100644
--- a/src/view.c
+++ b/src/view.c
@@ -1987,6 +1987,7 @@ move_to_front(struct view *view)
 		view->impl->move_to_front(view);
 	}
 	view->server->last_raised_view = view;
+	desktop_update_top_layer_visiblity(view->server);
 }
 
 static void
@@ -1998,6 +1999,7 @@ move_to_back(struct view *view)
 	if (view == view->server->last_raised_view) {
 		view->server->last_raised_view = NULL;
 	}
+	desktop_update_top_layer_visiblity(view->server);
 }
 
 /*

[Consolatis]

It also says the ordering within the same layer is undefined, so we can reverse the order of top panels and fullscreen windows, like my suggestion does.

That has been clarified in the the discussion of upstreaming the layershell protocol: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28/diffs#0f7d62083cb06bea09093cc4019184cc26dda1da_0_135

However, regardless of what the protocol says I think its fine to make panels visible when there is a window on top of a fullscreen one. Another option could be to simply un-fullscreen when another window is going to be rendered on top but that would be even more annoying.

We can remove the invisible exclusive zones of bottom panels if they are hidden by fullscreen windows, but I don't like updating output->usable_area and resizing windows every time the ordering of fullscreen window and bottom panel changes.

That wouldn't really help in this regard. I think we just have to accept fullscreen windows being rendered on top of bottom layershell clients when there is another view on top of the fullscreen one and if users (like myself) are annoyed by that behavior they can configure their panels to use the top layer instead.

[Consolatis]

Yeah.. that look weird. Not sure what is going on there.

I assume you can modify your waybar config to run in the bottom layer rather than in the top one, that could potentially work around the issue. We should still figure out why this happens and how to fix it though.

[guzz46]

When modifying waybar to run in the bottom layer the issue happens as soon as I open the steam client, it also happens if waybar is on the left of the screen or the bottom of the screen.

[Consolatis]

Layershell clients with exclusive zone (e.g. most panels like waybar) should be hidden as soon as a fullscreen application is started. I am not quite sure why that wasn't happening with Steam before. So the behavior of it being hidden when mpv is fullscreen is intended. However when then leaving fullscreen the bar should show up again. This might have something to do with how steam big picture mode is implemented (e.g. maybe as unmanaged fullscreen), I can't really test this on my system.

If you want the panel be visible at all times you'd need to use the "overlay" layer instead which will be rendered on top of fullscreen windows.

[guzz46]

When I set the layer in waybar to overlay the problem goes away, but the only issue then is when watching a video in fullscreen a portion of the video is hidden under waybar.

[Consolatis]

When I set the layer in waybar to overlay the problem goes away, but the only issue then is when watching a video in fullscreen a portion of the video is hidden under waybar.

Yes, that is why usually panels are configured for the "bottom" or "top" layers.

The actual question here is why steam big picture mode is not on top of the "top" layer waybar, if it was using fullscreen it should be but based on your video it isn't (at least initially). Somebody with Steam could maybe debug this a bit further, for example there might be an option to use A-Space to open the window menu for the Steam window and then rather than using fullscreen setting it to maximize and hide the decorations. If that works it could be set in a window rule instead of doing it manually. But I fear that it might not actually be a proper X11 window but an "unmanaged" one where this kind of trick would not work. Maybe that is also something that could be changed somewhere within steam (e.g. "fullscreen" via "borderless fullscreen" or something like that).

[guzz46]

I'll have a play around and see if I can find something that works, but if I don't run it in big picture mode then steam just opens to the tray, and if I click on the tray icon and select library or store nothing happens, the labwc window switcher doesn't even register that steam is running, so I kind of have to run it in big picture mode at the moment.

[guzz46]

I've found a bit of a workaround, by creating a window rule that puts steam always on the bottom, the only slight issue is the window switcher doesn't register that steam is open, and when playing a game the same issue happens with the panel, so you can't "alt tab" to the steam client, because it's not in the window switcher, and if you "alt tab" out of the game you can't select the steam client from waybar because the game is on top of the bar, I'll see if I can create a window rule that resizes the steam client so it's not taking up the entire screen, and set a position where it doesn't overlap the waybar.

Edit: OK so after setting a window rule that resizes and moves the steam client to where it doesn't touch waybar, the problem still happens when entering fullscreen either via MPV or via a youtube video, so it looks like setting steam client to always be below is currently the best work around as long as you don't mind the panel disappearing when you "alt tab" out of a game, this is the window rule.

  <windowRule identifier="steam" matchOnce="true">
    <skipTaskbar>no</skipTaskbar>
   <action name="ToggleAlwaysOnBottom"/>
  </windowRule>

[tokyo4j]

I reproduced this issue, but it will take some time to debug this since I lack knowledge of xwayland.

[guzz46]

For some reason I can now run steam in normal window mode, so I don't need the window rule to keep steam below, but I found the same thing happens when launching and playing a game, when you alt tab out of the game the game is on top of waybar.

[Consolatis]

For some reason I can now run steam in normal window mode, so I don't need the window rule to keep steam below, but I found the same thing happens when launching and playing a game, when you alt tab out of the game the game is on top of waybar.

Yes, fullscreen is supposed to always be on top of all layer windows < Overlay.
This behavior is slightly annoying though, I stumble on this as well when quickly A-Tabbing away from a fullscreen window. It is difficult to solve because we can't just use fullscreen + focused as condition (you could have a panel and fullscreen video on a second monitor but work on the first monitor). So I am not quite sure how to tackle this issue.

[Consolatis]

How about showing top layer if there's any windows above fullscreen window?

Hm.. right. I think that could work.

Edit:
Only for TOP layershell clients though, BOTTOM ones with exclusive zone won't be affected.
However one could argue that this is an acceptable compromise.

[tokyo4j]

BOTTOM ones with exclusive zone won't be affected.

I think this is the limitation of the protocol.

As the protocol says normal windows are placed between top and bottom and fullscreen windows are in top, we should never show bottom panels when fullscreen windows are present as long as exclusive zones of bottom layer don't occlude fullscreen windows.

It also says the ordering within the same layer is undefined, so we can reverse the order of top panels and fullscreen windows, like my suggestion does.

So I think my suggestion is the best we could do within the protocol and at least KDE Plasma (which also implements wlr-layer-shell) seems to work in this way.
Of course this will require some discussion.

EDIT:
We can remove the invisible exclusive zones of bottom panels if they are hidden by fullscreen windows, but I don't like updating output->usable_area and resizing windows every time the ordering of fullscreen window and bottom panel changes.

[tokyo4j]

I realized my statement didn't make sense. If we strictly follow the protocol, we can never raise a normal window above a fullscreen window in the first place. Also, the protocol uses the word "typically" to indicate it's not forcing the ordering of windows. This is my English issue.

Thank you for the advises anyway. I'll investigate about the protocol and possible implementations.