[PR #28] [CLOSED] fix: propagate runtime resolution changes to connected clients #30

New issue

Closed

opened 2026-10-15 12:47:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:47:41 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/28
Author: @JBailes
Created: 4/24/2026
Status: ❌ Closed

Base: stable ← Head: fix/resolution-switching

📝 Commits (1)

f732af5 fix: propagate runtime resolution changes to connected clients

📊 Changes

1 file changed (+6 additions, -6 deletions)

View changed files

📝 wayland-display-core/src/comp/mod.rs (+6 -6)

📄 Description

Summary

Closes the long-standing TODO in wayland-display-core/src/comp/mod.rs that silently drops a second Command::VideoInfo once the compositor output exists. Before this change, calling set_resolution() after the first frame would update the gstreamer caps/buffer size, but connected Wayland clients kept observing the original wl_output.mode and mapped xdg_toplevels kept the original size — the compositor never re-broadcast the new state.

The fix

Drop the early return from the Command::VideoInfo handler.
Track output_already_running so space.map_output(&output, (0, 0)) still only runs once (re-mapping would duplicate the output in the space).
Everything else is safe and desirable to re-run on every VideoInfo:
- output.change_current_state(Some(mode), …) already broadcasts wl_output.geometry / wl_output.mode to bound clients.
- OutputDamageTracker::from_output is rebuilt for the new size.
- The allocator is rebuilt (GsGlesbuffer / GsDmaBuf / GsCUDABuf) — necessary for DMA-BUF resolution switching, which is what the original TODO called out.
- The existing toplevel loop at the tail of the branch already resizes every mapped window (with_pending_state / send_configure), so clients see a fresh xdg_toplevel.configure with the new dimensions.

Net diff: 6 lines changed in one file.

Reproduction / validation

Validated against a new [WAYLAND][resolution] Catch2 integration test harness added in games-on-whales/wolf#399, which drives a real Wayland client against the virtual display and asserts, among other things:

wl_output advertises the configured mode to the client on bind.
xdg_toplevel receives an initial configure matching the output size.
A runtime set_resolution() call propagates new wl_output.mode and xdg_toplevel.configure events to the connected client.
Multiple resolution toggles each propagate.
A framerate-only change updates wl_output.mode.refresh.
Downscales never leave the client seeing stale larger dimensions.

Tests 3–6 reproduce the bug on stable and are green with this fix applied.

Test plan

cargo check -p wayland-display-core — clean (verified).
cargo fmt --check — clean (verified).
Wolf-side Catch2 integration tests (wolf#399 [WAYLAND][resolution]) turn green once this lands.
Manual: connect a Moonlight client to Wolf, start a session, change client resolution mid-session, confirm the Wayland app resizes instead of rendering to a stale output.

Relation to PR #27

An earlier draft PR (#27 codex/output-resize-updates) proposes a similar approach, plus additional Fullscreen / Activated state bits on the toplevel pending-state. This PR intentionally keeps the diff minimal — only what's needed to close the resolution-switching gap. Happy to fold in the extra state bits here or supersede either direction based on maintainer preference.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/gst-wayland-display/pull/28 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 4/24/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `fix/resolution-switching` --- ### 📝 Commits (1) - [`f732af5`](https://github.com/games-on-whales/gst-wayland-display/commit/f732af57d267921c94bc3aa660e50468bb335546) fix: propagate runtime resolution changes to connected clients ### 📊 Changes **1 file changed** (+6 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/mod.rs` (+6 -6) </details> ### 📄 Description ## Summary Closes the long-standing TODO in `wayland-display-core/src/comp/mod.rs` that silently drops a second `Command::VideoInfo` once the compositor output exists. Before this change, calling `set_resolution()` after the first frame would update the gstreamer caps/buffer size, but connected Wayland clients kept observing the original `wl_output.mode` and mapped `xdg_toplevel`s kept the original size — the compositor never re-broadcast the new state. ## The fix - Drop the early `return` from the `Command::VideoInfo` handler. - Track `output_already_running` so `space.map_output(&output, (0, 0))` still only runs once (re-mapping would duplicate the output in the space). - Everything else is safe and desirable to re-run on every VideoInfo: - `output.change_current_state(Some(mode), …)` already broadcasts `wl_output.geometry` / `wl_output.mode` to bound clients. - `OutputDamageTracker::from_output` is rebuilt for the new size. - The allocator is rebuilt (`GsGlesbuffer` / `GsDmaBuf` / `GsCUDABuf`) — necessary for DMA-BUF resolution switching, which is what the original TODO called out. - The existing toplevel loop at the tail of the branch already resizes every mapped window (`with_pending_state` / `send_configure`), so clients see a fresh `xdg_toplevel.configure` with the new dimensions. Net diff: 6 lines changed in one file. ## Reproduction / validation Validated against a new `[WAYLAND][resolution]` Catch2 integration test harness added in **games-on-whales/wolf#399**, which drives a real Wayland client against the virtual display and asserts, among other things: 1. `wl_output` advertises the configured mode to the client on bind. 2. `xdg_toplevel` receives an initial configure matching the output size. 3. A runtime `set_resolution()` call propagates new `wl_output.mode` and `xdg_toplevel.configure` events to the connected client. 4. Multiple resolution toggles each propagate. 5. A framerate-only change updates `wl_output.mode.refresh`. 6. Downscales never leave the client seeing stale larger dimensions. Tests 3–6 reproduce the bug on `stable` and are green with this fix applied. ## Test plan - [ ] `cargo check -p wayland-display-core` — clean (verified). - [ ] `cargo fmt --check` — clean (verified). - [ ] Wolf-side Catch2 integration tests (wolf#399 `[WAYLAND][resolution]`) turn green once this lands. - [ ] Manual: connect a Moonlight client to Wolf, start a session, change client resolution mid-session, confirm the Wayland app resizes instead of rendering to a stale output. ## Relation to PR #27 An earlier draft PR (#27 `codex/output-resize-updates`) proposes a similar approach, plus additional `Fullscreen` / `Activated` state bits on the toplevel pending-state. This PR intentionally keeps the diff minimal — only what's needed to close the resolution-switching gap. Happy to fold in the extra state bits here or supersede either direction based on maintainer preference. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:47:41 +00:00