Skip to content

[Wayland] Add support for XDG_TOPLEVEL_STATE_SUSPENDED#19208

Closed
Sunderland93 wants to merge 11 commits into
libretro:masterfrom
Sunderland93:toplevel_suspend
Closed

[Wayland] Add support for XDG_TOPLEVEL_STATE_SUSPENDED#19208
Sunderland93 wants to merge 11 commits into
libretro:masterfrom
Sunderland93:toplevel_suspend

Conversation

@Sunderland93

Copy link
Copy Markdown
Contributor

Guidelines

  1. Rebase before opening a pull request
  2. If you are sending several unrelated fixes or features, use a branch and a separate pull request for each
  3. If possible try squashing everything in a single commit. This is particularly beneficial in the case of feature merges since it allows easy bisecting when a problem arises
  4. RetroArch codebase follows C89 coding rules for portability across many old platforms check using C89_BUILD=1

Description

This PR adds support for XDG_TOPLEVEL_STATE_SUSPENDED event. When surface is occluded or minimized, compositor send this hint so app can, e,g, stop requesting frame callbacks. (on EGL) or skip vulklan_acquire_next_image on Vulkan. When surface become visible, compositor sends configure without suspend hint.

Related Issues

[Any issues this pull request may be addressing]

Related Pull Requests

[Any other PRs from related repositories that might be needed for this pull request to work]

Reviewers

[If possible @mention all the people that should review your pull request]

LibretroAdmin pushed a commit that referenced this pull request Jul 20, 2026
Reimplementation of #19208 (Sunderland93) on top of the deduped
(89f38ac) and latched (7eefa40) configure handling, with
backwards compatibility preserved by construction throughout.

Bind xdg_wm_base up to v6 (the in-tree generated protocol code is
already v7; the vendored XML is synced from the PR so the generator
output matches the committed sources).  Compositors advertising less
bind their own version - verified against Weston 13 (advertises v5):
the negotiated bind is 5, and the v5 wm_capabilities event, which
would previously have been a NULL-slot dispatch had the bind ever
exceeded 3, is now absorbed by an explicit stub alongside the v4
configure_bounds stub.  Both stubs live once in the common listener
thanks to the dedupe.

SUSPENDED (since v6) is routed through the configure latch: recorded
into cfg_pending at xdg_toplevel.configure, applied to wl->suspended
at xdg_surface.configure.  The libdecor path - which the original PR
missed entirely, leaving the feature dead on libdecor sessions - sets
the flag from LIBDECOR_WINDOW_STATE_SUSPENDED, written as the
ABI-stable bit value so pre-0.2 libdecor headers still compile;
older runtimes simply never set it.

Behavior while suspended:
- EGL: skip the frame-callback wait (hidden surfaces receive no
  callbacks; waiting burns the 50ms deadline every frame).
- Vulkan: skip present/acquire, keep the event queue flushed so the
  resume configure is seen, and sleep 10ms only when swap_interval
  is nonzero.  The original PR slept unconditionally, which would
  have newly throttled fast-forward while hidden; gating on the
  vsync interval keeps interval==0 behavior identical to before.

Compatibility summary: on any compositor not sending SUSPENDED
(everything below xdg_wm_base v6, including Weston 13) wl->suspended
remains false and every new branch is a no-op; the v4/v5 stubs only
make previously-unreachable events safe.

Verified: full build; A/B under headless Weston 13 - version
negotiation, wm_capabilities delivery into the stub, fullscreen
startup unchanged, zero protocol errors.  NOT runtime-verified: the
suspend branches themselves, since Weston 13 caps at v5; they need a
compositor with xdg_wm_base >= 6 (GNOME 44+/KWin 5.27+/recent
wlroots) and a minimize/occlude cycle.
@LibretroAdmin

Copy link
Copy Markdown
Contributor

Check if this commit can replace this PR
cf89e20
I had to reimplement it based on some prior PRs

@Sunderland93

Copy link
Copy Markdown
Contributor Author

Check if this commit can replace this PR cf89e20 I had to reimplement it based on some prior PRs

Yes, thank tou

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.

2 participants