(WIP) wayland: add support for XDG_TOPLEVEL_STATE_SUSPENDED

[Sunderland93]

This adds support for suspended toplevel state introduced in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/201

Currently I'm not sure how to properly plug this event to RetroArch's window, so WIP for now

@ColinKinloch

[ColinKinloch]

This is defined in the header generated by wayland-scanner from xdg-shell.xml when./configure is run.
Making sure it's defined more likely to hide issues than fix them.

[Sunderland93]

Removed

[ColinKinloch]

I meant that the #define XDG_TOPLEVEL_STATE_SUSPENDED was unnecessary.
However trying it on my machine I see that XDG_TOPLEVEL_STATE_SUSPENDED isn't being defined in ./gfx/common/wayland/xdg-shell.h because ./gfx/common/wayland/generate_wayland_protos.sh is selecting my distros protocol files which are not as up to date.

[Sunderland93]

I have increased requirement wayland-protocols version to 1.32, so if it's not found - bundled (and updated) xdg-shell will be used instead.

[ColinKinloch]

Hah, I completely missed that.
I was trying to hack pkg-config support into ./gfx/common/wayland/generate_wayland_protos.sh.

[Sunderland93]

Hmm, after compiling with this PR and run on KDE Plasma Wayland I got this error:

listener function for opcode 2 of xdg_toplevel is NULL

but on Sway it works fine

[ColinKinloch]

Ah, yes, that is because you've upped xdg_toplevel support to version 6.
Which means you also need to implement version 4 and 5. Each adds one event to the xdg_toplevel listener so it shouldn't be too complex.
Version 4: xdg_toplevel::configure_bounds
Version 5: xdg_toplevel::wm_capabilities

Empty functions may be fine.

[Sunderland93]

Should I make a separate PR for this?

[ColinKinloch]

My gut says no. If the implementation of either event handler ends up complex then split it off.

[Sunderland93]

Done

[Sunderland93]

@ColinKinloch should I also adapt libdecor part to this? https://gitlab.freedesktop.org/libdecor/libdecor/-/merge_requests/126

[ColinKinloch]

Looks like the latest release of libdecor was 0.1.1 10 months ago, whereas suspend support was merged last month.
If you can hide it behind an #ifdef or something?
I guess just make sure adding suspend support doesn't break libdecor.

[Sunderland93]

Also, does RetroArch already have an interface to interrupt window rendering (render loop) that could be bound to the suspended state?

[ColinKinloch]

I have a pretty poor understanding of the RetroArch code base outside of the Wayland code to be honest.
It's could be you should implement it in gfx/drivers_context/wayland_ctx.c and gfx/drivers_context/wayland_vk_ctx.c or maybe runloop.c.

[ColinKinloch]

I've had another look at this. Here are my thoughts:

Now that libdecor 0.2.x is stable you should add support for that.

I'm still not exactly sure where implement suspend in retroarch. I guess the goal is to avoid rendering frames when the surface is suspended so that the game loop, audio etc are still processed. Adding if (wl->suspended) return; at the start of gfx_ctx_wl_swap_buffers is a rudimentary option I've used while investigating this.

Logging when the surface suspends and resumes in xdg_toplevel_handle_configure_common shows that the suspend event doesn't arrive until the surface is resumed. It seems that once the surface is off screen retroarch stalls indefinitely at vkQueuePresentKHR so part of the solution may involve adding a timeout to that.

[Sunderland93]

Hello. I am unable to continue working on this PR at this time, so you can take it over if you'd like

[LibretroAdmin]

Hi there @Sunderland93 and @ColinKinloch , sorry for the neglect with this PR.

Are you guys still willing to finalize this and get it incorporated, or has another PR superseded it? I'm still interested in getting this across the finish line. Thanks.