`OnDemand` interactivity not working on Sway about cosmic-panel HOT 7 CLOSED

It was a wlroots / sway bug:

• swaywm/sway#7260
• swaywm/sway#7265

Hyprland has the same issue:

• hyprwm/Hyprland#2264

Background: wlroots used to always announce version 4 of the protocol which added support for ON_DEMAND but not all wlroots based compositors added that support. Hyprland and old versions of sway seem to treat it the same as EXCLUSIVE instead. This has been fixed in wlroots by allowing compositors to supply the supported version (e.g. 3 if not supporting ON_DEMAND). Panels could thus check for the announced version and then either use EXCLUSIVE / NONE if version 3 is announced or ON_DEMAND for version 4.

from cosmic-panel.

Yeah, the definition of the protocol is written in a way that allows a lot of flexibility in how it works. But it doesn't seem quite right given clicking on a window and using super+hjkl doesn't work.

I guess swaybar may require keyboard interactivity. Not sure what else would. Given the protocol specifically mentions panels as a use case for on_demand, and the protocol was defined by wlroots, it seems like there should be a way for this to work properly.

Edit: Hm, clicking on another window results in the panel getting wl_keyboard::leave immediately followed by wl_keyboard::enter. Seems like something sway/wlroots shouldn't be doing given it's not showing any request from the client to grab focus back or anything...

from cosmic-panel.

Looking at apt rdepends libgtk-layer-shell0, vala-panel and mate-panel are a couple panels using layer-shell. But they use the default none keyboard interactivity in gtk-layer-shell. Modifying mate-panel to use on_demand, the same issue seems to occurs (but that enables keyboard interaction with the menus in mate panel itself, which naturally doesn't work with none).

So cosmic-panel doesn't seem to be doing anything too unusual, and it may be a wlroots or sway issue. Perhaps the on_demand feature worked initially but broke if it isn't really used.

from cosmic-panel.

I'm not sure that this is an issue in the panel, but I have also noticed this for a while. I believe it could be specific behavior with sway considering that the compositor would be responsible for handling which clients are sent input events, unless somehow the keyboard interactivity for the layer surfaces are being set incorrectly in the panel. Perhaps there is a way that the panel needs to request to be unfocused, or in sway there is a keybinding for unfocusing it?

Nevertheless, it is possible for a compositor to require a special interaction to focus or unfocus layer shell surface
https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity:entry:on_demand

from cosmic-panel.

Looking at the source for waybar & swaybar, it seems to me that both set keyboard interactivity to None. Maybe there is another panel that uses on_demand to cross reference with?

from cosmic-panel.

Ah, good to hear it's fixed. So that explains why I wasn't able to reproduce it recently.

This seems to be an awkward thing with Wayland in general: with a compositor/library split, implementing a new protocol version in the library isn't necessary possible without compositor changes.

from cosmic-panel.

Thanks, Consolatis for highlighting that this was resolved.

from cosmic-panel.