Skip to content

fix(2214): fallback to xdg-shell when wlr-layer-shell is not available#2297

Open
giulianopz wants to merge 1 commit into
davatorium:nextfrom
giulianopz:2214
Open

fix(2214): fallback to xdg-shell when wlr-layer-shell is not available#2297
giulianopz wants to merge 1 commit into
davatorium:nextfrom
giulianopz:2214

Conversation

@giulianopz

@giulianopz giulianopz commented May 23, 2026

Copy link
Copy Markdown

The current PR fixes the issue #2214.

Rofi's Wayland backend currently aborts on any compositor that doesn't support zwlr_layer_shell_v1:

Wayland-ERROR: Rofi on wayland requires support for the layer shell protocol

That affects GNOME (Mutter), Weston, et alia... (see https://wayland.app/protocols/wlr-layer-shell-unstable-v1#compositor-support), since wlr-layer-shell is a wlroots protocol that those compositors don't implement and don't plan to (see mutter#973).
On these sessions rofi currently has no Wayland code path at all and falls back to XWayland — which brings the well-known problem of a broken keyboard when launched from a compositor shortcut (XWayland keyboard grabs only work when focus is already in the X11 realm, for example, from a terminal emulator by unsetting WAYLAND_DISPLAY).

This PR adds a fallback path that uses xdg-shell, xdg-activation-v1, and xdg-popup with xdg-positioner when wlr-layer-shell isn't available, so rofi runs as a native Wayland client on those compositors. The layer-shell code path is untouched and remains preferred when available; the new code is gated on: wayland->layer_shell == NULL


Beware that this PR is heavily LLM-assisted. I'm not a Wayland expert, but from a bunch of posts I've read (actually, even the original patch by @lbonn to support Wayland mentions it), falling back to the xdg-shell protocol is the only way to make rofi work under a Wayland session on GNOME/Mutter: at the moment, a large pool of Linux desktop users (including me) can no longer use rofi... I don't know your stance on the LLM transition the entire world is facing right now. Feel free to take this code and improve it, or to just ignore it if you prefer. For what it's worth, I can say that I've been running this patch for a week and it works: at least, I've resolved the rofi-on-GNOME issue for myself.

Rofi's Wayland backend currently aborts on any compositor that doesn't
support `zwlr_layer_shell_v1`:

Wayland-ERROR: Rofi on wayland requires support for the layer shell protocol

That affects GNOME (Mutter), Weston, et alia...
(see https://wayland.app/protocols/wlr-layer-shell-unstable-v1#compositor-support),
since wlr-layer-shell is a wlroots protocol that those
compositors don't implement and don't plan to (see https://gitlab.gnome.org/GNOME/mutter/-/work_items/973#note_668502).
On these sessions rofi currently has no Wayland code path at all
and falls back to XWayland — which brings to the well-known problem
of a broken keyboard when launched from a compositor shortcut
(XWayland keyboard grabs only work when focus is already in the X11
realm, for example, from a terminal emulator by unsetting WAYLAND_DISPLAY).

This PR adds a fallback path that uses xdg-shell,
xdg-activation-v1, and xdg-popup with xdg-positioner when
wlr-layer-shell isn't available, so rofi runs as a native Wayland client on
those compositors. The layer-shell code path is untouched and remains
preferred when available; the new code is gated on:
wayland->layer_shell == NULL

Signed-off-by: Giuliano Panzironi <panzironi.giuliano@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant