From c991de38dd13a238ad7d92fde68646423936d932 Mon Sep 17 00:00:00 2001 From: Erik Date: Thu, 13 Aug 2026 16:36:54 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20file=20#388=20=E2=80=94=20fullscreen-st?= =?UTF-8?q?ate=20video-mode=20crash=20+=20silent=20resolution-pick=20no-op?= =?UTF-8?q?=20(user=20gate=20session=20evidence)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5 --- docs/ISSUES.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 4b15cd0b..4a8cd1e9 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -24,6 +24,43 @@ What does NOT go here: - Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending. - Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed. +## #388 — CRASH: unhandled GlfwException "Failed to set video mode: Graphics mode not supported" during a fullscreen-state resolution/settings apply; and fullscreen/maximized windows silently ignore resolution picks + +**Status:** OPEN — filed 2026-08-13 from the user's live gate session +(log: scratchpad `rdp-verify.log` / task b7rd8zkd4, exit 29 after an +unhandled `Silk.NET.GLFW.GlfwException`). Two distinct facts from the +same session, both in the #376/#377 fullscreen family: + +1. **The crash.** With the persisted display state carrying + `fullscreen: true`, a settings apply attempted a GLFW video-mode + change ("Failed to set video mode: Graphics mode not supported"). + The first failure surfaced as `settings: display save failed: + PlatformError...` (caught), then a second fired as an UNHANDLED + exception from GLFW's error callback and killed the process + mid-session. Likely path: `SilkRuntimeDisplayWindowTarget.Apply` + writing `_window.Size`/`WindowState` while the window is in Silk + fullscreen — GLFW size writes on a fullscreen window are video-mode + requests, and an unsupported mode (816x639 was in flight) is fatal + through Silk's throwing error callback. Root-cause exactly before + fixing; the crash also re-saved `fullscreen: true`, arming the #377 + startup crash on the NEXT launch (recovered by hand-editing + settings.json back to false, the documented #377 recovery). +2. **The silent no-op.** Earlier in the same log, five consecutive + resolution picks (2560x1440 / 3840x2160 / 1366x768 / 800x600 x2, all + "window was 2056x1290") produced NO framebuffer-resize event and NO + swapchain recreation — the Size writes were silently ignored by the + window state the client was in (fullscreen/maximized family). This is + the concrete mechanism behind the user's "the resolution does not + change" report in that state. In plain windowed state the same + session's own picks DID work end-to-end (`pick 800x600 → event + 800x600 → swapchain recreated 800x600 ok=True`, #387's chain). + +Both fold into the promoted fullscreen work block (#376 native +glfwSetWindowMonitor + mode-list validation, #377 startup crash): the +Apply path must become state-aware — windowed pick = window resize +(shipped, #387); fullscreen pick = validated native mode switch; never +a raw Size write against a fullscreen window. + ## #387 — Window resize never recreates the Vulkan swapchain: resolution picks stretch the image instead of changing the pixel count **Status:** DONE 2026-08-13 (this commit) — pending the user's re-check.