search

wmww / gtk4-layer-shell

A library to create panels and other desktop components for Wayland using the Layer Shell protocol and GTK4
MIT License
128 stars 4 forks source link

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

Open madonuko opened 4 months ago

madonuko commented 4 months ago

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

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 commented 4 months ago

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 commented 4 months ago

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

wmww commented 4 months ago

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.