[BUG] error(zwlr_layer_surface_v1@41, 2, "layer_surface has never been configured")

[madonuko]

Running gtk4-layer-shell (rust) on my computer under Wayfire causes this (consistently):

• logs
• code

This issue is not reproducible on my colleagues' computers and only my machine with Wayfire. Not reproducible under Sway.

Changing the code to this also causes the issue:

let window = libhelium::Window::new();
window.init_layer_shell();
window.set_layer(Layer::Overlay);

The problem seems to be that its buffers get attached before configure(). I've talked to the Wayfire devs (big thanks to everyone there!) and we've confirmed the issue comes from gtk4-layer-shell.

See https://github.com/pentamassiv/gtk4-layer-shell-gir/issues/28

[pentamassiv]

Which version of gtk4-layer-shell is this? The new version fixed some segfaults (see https://github.com/wmww/gtk4-layer-shell/issues/23)

[madonuko]

I'm currently on latest gtk4-layer-shell-1.0.2-1.fc39.x86_64 provided by Fedora 39.

[wmww]

Hmm, that does seem wrong, but it's unclear to me what could be happening. The rules of the configure/attach dance should be the same between XDG shell and Layer Shell, and we should simply be proxying the XDG shell calls so as long as GTK is using XDG shell correctly we should be using Layer Shell correctly.

It's also strange it doesn't happen on Sway, since the relevant checks are built into wlroots.

If a minimal reproducer in C were possible, or a minimal self-contained Rust project, that would certainly make debugging easier. If it's not reproducible between machines that's going to be very hard to solve, until you work out what the difference is.

Perhaps try not initializing Layer Shell for the window, and see if it runs into the same bug on GTK's XDG shell implementation? Maybe check the logs in that case, and see if that effects the order of attach/configure messages?

You could also try setting a wayland-debug breakpoint on .attach in GDB mode and getting a stack trace for what's calling the erroneous .attach (wayland-debug -b .attach -g <program>), though that may not end up being interesting.

[Ferdi265]

I'm hitting this in the GTK4 port of SwayOSD, both with Sway 1.9 and git master. I'll try your suggestions and see if I can figure out what's happening.

[Ferdi265]

I can also reproduce this with only a slightly modified example program:

For the Python example:

diff --git a/examples/simple-example.py b/examples/simple-example.py
index 630d722..6f6074e 100644
--- a/examples/simple-example.py
+++ b/examples/simple-example.py
@@ -23,6 +23,8 @@ def on_activate(app):
     LayerShell.set_margin(window, LayerShell.Edge.TOP, 20)
     LayerShell.auto_exclusive_zone_enable(window)

+    window.connect('map', lambda x: LayerShell.set_margin(window, LayerShell.Edge.TOP, 30))
+
     button = Gtk.Button(label="GTK4 Layer Shell with Python")
     button.connect('clicked', lambda x: window.close())
     window.set_child(button)

For the C Example:

diff --git a/examples/simple-example.c b/examples/simple-example.c
index 939e932..304f12d 100644
--- a/examples/simple-example.c
+++ b/examples/simple-example.c
@@ -1,6 +1,13 @@
 #include "gtk4-layer-shell.h"
 #include <gtk/gtk.h>

+static void
+on_map (GtkWindow* gtk_window, gpointer _data)
+{
+    (void)_data;
+    gtk_layer_set_margin (gtk_window, GTK_LAYER_SHELL_EDGE_TOP, 30);
+}
+
 static void
 activate (GtkApplication* app, void *_data)
 {
@@ -35,6 +42,8 @@ activate (GtkApplication* app, void *_data)
         gtk_layer_set_anchor (gtk_window, i, anchors[i]);
     }

+    g_signal_connect(gtk_window, "map", G_CALLBACK (on_map), NULL);
+
     // Set up a widget
     GtkWidget *label = gtk_label_new ("");
     gtk_label_set_markup (GTK_LABEL (label),

[Ferdi265]

Hmm, that does seem wrong, but it's unclear to me what could be happening. The rules of the configure/attach dance should be the same between XDG shell and Layer Shell, and we should simply be proxying the XDG shell calls so as long as GTK is using XDG shell correctly we should be using Layer Shell correctly.

It's also strange it doesn't happen on Sway, since the relevant checks are built into wlroots.

If a minimal reproducer in C were possible, or a minimal self-contained Rust project, that would certainly make debugging easier. If it's not reproducible between machines that's going to be very hard to solve, until you work out what the difference is.

Perhaps try not initializing Layer Shell for the window, and see if it runs into the same bug on GTK's XDG shell implementation? Maybe check the logs in that case, and see if that effects the order of attach/configure messages?

You could also try setting a wayland-debug breakpoint on .attach in GDB mode and getting a stack trace for what's calling the erroneous .attach (wayland-debug -b .attach -g <program>), though that may not end up being interesting.

Hmm, that does seem wrong, but it's unclear to me what could be happening. The rules of the configure/attach dance should be the same between XDG shell and Layer Shell, and we should simply be proxying the XDG shell calls so as long as GTK is using XDG shell correctly we should be using Layer Shell correctly.

It's also strange it doesn't happen on Sway, since the relevant checks are built into wlroots.

If a minimal reproducer in C were possible, or a minimal self-contained Rust project, that would certainly make debugging easier. If it's not reproducible between machines that's going to be very hard to solve, until you work out what the difference is.

Perhaps try not initializing Layer Shell for the window, and see if it runs into the same bug on GTK's XDG shell implementation? Maybe check the logs in that case, and see if that effects the order of attach/configure messages?

You could also try setting a wayland-debug breakpoint on .attach in GDB mode and getting a stack trace for what's calling the erroneous .attach (wayland-debug -b .attach -g <program>), though that may not end up being interesting.

I looked into the wayland debug trace, with added logging and to me it looks like the following is happening:

• GTK is doing something that calls needs_commit()
• layer_surface_configure_xdg_surface sends a fake xdg_toplevel->configure and xdg_surface->configure event to GTK without receiving a real zwlr_layer_surface_v1->configure beforehand (!!)
• GTK now sends an xdg_surface->ack_configure request, which gtk4-layer-shell ignores since it doesn't have a real stored serial yet.
• GTK thinks all is well and starts attaching buffers to the surface, which explodes.