erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

docs: file #388 — fullscreen-state video-mode crash + silent resolution-pick no-op (user gate session evidence)

Browse source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-13 16:36:54 +02:00
parent a57287f8ad
commit c991de38dd
1 changed files with 37 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

37
docs/ISSUES.md
View file

@ -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. - 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. - 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 ## #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. **Status:** DONE 2026-08-13 (this commit) — pending the user's re-check.