https://bugs.kde.org/show_bug.cgi?id=503121
Bug ID: 503121
Summary: wlr-layer-shell bug: No configure event is sent after
the layer surfaceis unmapped and the remapped
Classification: Plasma
Product: kwin
Version: 6.3.4
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: kwin-bugs-n...@kde.org
Reporter: ko...@kovidgoyal.net
Target Milestone: ---
Created attachment 180486
--> https://bugs.kde.org/attachment.cgi?id=180486&action=edit
Full WAYLAND_DEBUG=1 log
SUMMARY
The wlr-layer-shell implementation in kwin has a bug where if the surface is
unmapped by doing:
wl_surface_attach(surface, NULL, 0, 0); wl_surface_commit(surface);
and then later remapped by doing:
wl_surface_commit(surface);
no layer shell configure event is sent by kwin. Quoting the spec from
https://wayland.app/protocols/wlr-layer-shell-unstable-v1
Attaching a null buffer to a layer surface unmaps it.
Unmapping a layer_surface means that the surface cannot be shown by the
compositor until it is explicitly mapped again. The layer_surface returns to
the state it had right after layer_shell.get_layer_surface. The client can
re-map the surface by performing a commit without any buffer attached, waiting
for a configure event and handling it as usual.
kwin is not sending the configure event at all. This works as expected
on sway and hyprland.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
ADDITIONAL INFORMATION
Extract from the WAYLAND_DEBUG=1 log:
[2733789.462] {Default Queue} -> wl_surface#29.attach(nil, 0, 0)
[2733789.474] {Default Queue} -> wl_surface#29.commit()
[2733792.214] {Default Queue} wl_keyboard#28.leave(1140, wl_surface#29)
[2741813.411] {Default Queue} -> wl_surface#29.commit()
[2755957.349] {Default Queue} -> wp_fractional_scale_v1#30.destroy()
The first line shows the surface being unmapped with a nil buffer and
committed. Then one second later, the surface is committed again,
nothing is received from kwin for an additional 14 seconds at which
point the application quits starting the destroy sequence.
--
You are receiving this mail because:
You are watching all bug changes.
