Add support for layer-shell on_demand keyboard interactivity

[ErikReider]

Supersedes #5974

Tested (from original PR) with gtk-layer-demo:

• xdg toplevel + layer-surface/top/on-demand
• xdg toplevel + layer-surface/top/on-demand + layer-surface/top/exclusive
• xdg toplevel + layer-surface/top/on-demand + layer-surface/overlay/exclusive
• layer-surface/top/exclusive + layer-surface/top/none: Should be able to interact with none layer, popups, and subsurfaces(buttons, no keyboard input)
• focus_follows_mouse
• layer-surface/top/on-demand + layer-surface/top/exclusive, on-demand only focused when focused inside of bounds while exclusive is focused otherwise (also outside of its bounds)
• layer-surface/top/exclusive + layer-surface/top/exclusive: Layer has focus until the cursor enters/clicks within the other layers bounds
• Keyboard input is only available for EXCLUSIVE and ON_DEMAND surfaces
• Interact buttons in layers/subsurfaces/popups while NONE exclusive
• Clicking on xdg_popups/layer sub-surfaces works with any mode
• return keyboard focus after destroying on-demand layer surface

More test cases would be appreciated :)

[kennylevinsen]

This PR allows for entering text into textboxes while the layer is focused.

How was the bug reproduced? Is it with or without keyboard exclusivity?

The git history of this PR is a little foo. Having a commit for each of the fixes with a title and description that fits would be best.

[ErikReider]

How was the bug reproduced? Is it with or without keyboard exclusivity?

This was tested with a layer without any keyboard exclusivity (a notification from swaync with this PR). In the video below, the popup notification was tested while the second layer has keyboard exclusivity and covers the whole output (it's transparent).

2023-05-16.11-09-53.1.mp4

Prior to the fixes, you'd be able to focus and move views below an exclusive layer shown in the video below:

2023-05-16.11-19-57.1.mp4

The git history of this PR is a little foo. Having a commit for each of the fixes with a title and description that fits would be best.

I'm on it!

[ErikReider]

I removed the commit that disallowed non-keyboard exclusive layers from receiving mouse clicks while there being a exclusive layer beside it (ex: waybar receiving clicks while rofi is visible), so ignore that part in the videos above.

[kennylevinsen]

Hmm I'm a little confused between the original PR description and what the video displays.

A few notes about keyboard interactivity:

• It is only meant to affect (and if exclusive, steal) keyboard input and focus. Pointer, touch and tablet input and focus is not constrained and should always work as normal. This seems to be changed here.
• Keyboard interactivity defaults to none, where keyboard focus should never be granted to the surface.
• For exclusive, given a surface in TOP or OVERLAY, the top-most surface should be granted unconditional keyboard focus as long as it is mapped.
• For on_demand, the layer surface should behave like a normal surface.

More info here: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity

SwayNotificationCenter popups with a text field would definitely want on_demand. sway does not seem to currently handle on_demand, and might be treating it as exclusive by accident as it just checks if (keyboard_interactivity), only distinguishing between 0 (none) and anything else. We need to make the handling of the two original types explicit checks, allowing us to fall back to normal focus logic for on_demand.

[ErikReider]

Makes sense. So adding a check if the surface is requesting on_demand would be fine then?

[ErikReider]

I've got the changes necessary to advertise ON_DEMAND, should I create a new PR and close this one or change the title, desc, and redo the commits? @kennylevinsen

[kennylevinsen]

Either works!

[ErikReider]

Updated everything, would you like a clean commit history too?

[kennylevinsen]

Looking better! Still a thing remaining though. :)

[ErikReider]

Anything else that needs to be done?

[kennylevinsen]

LGTM, thanks!

[kennylevinsen]

@ErikReider Do you want to reword the git commits before we merge? They talk about the original version which had the wrong focus behavior. A conflict also snuck in in the meantime.

Will be merged when that is out of the way. :)