The console UI died on any Vulkan loader newer than the version we asked for #204

Merged

enricobuehler merged 1 commits from worktree-deck-skia-browse-fix into main 2026-08-13 20:26:26 +00:00

Conversation 0 Commits 1 Files Changed 4

+111 -8

1 Commits

Author	SHA1	Message	Date
enricobuehler	fbbfce9b0e	fix(console-ui): Skia sized its function table to the loader, not to what we promised ... The skia-safe 0.87 -> 0.99 move swapped `BackendContext::new` for `new_builder(..., None)` and recorded the `None` as "byte-for-byte what the (now removed) `BackendContext::new` did". That is true of the VALUE and false of the BEHAVIOUR. `None` leaves Skia's `fMaxAPIVersion` at its `0` sentinel, and the newer Skia acts on that sentinel by falling back to `vkEnumerateInstanceVersion()` -- the LOADER's ceiling, not ours. The presenter declares 1.3; a current Mesa answers 1.4 (1.4.321 on SteamOS 3.7, host and inside the flatpak sandbox alike). Skia then validates a 1.4 function table against an instance that only ever promised 1.3, `vkGetDeviceProcAddr` returns null for the entry points in between, validation fails, and `make_vulkan` hands back `None`. At 0.87 the same sentinel was inert, because that Skia knew nothing of Vulkan 1.4 -- which is why this surfaced the moment 0.28.0 landed. `run.rs` makes an overlay that cannot init fatal for `--browse`, so on the Steam Deck the console home died on update: the Decky panel's button and the gamepad-UI library shortcut both launch `PF_BROWSE=1`, and neither would open. In a stream the same failure only warns, so those sessions quietly lost their stats OSD and capture HUD instead. `pf-presenter`'s `vk` module is `cfg(any(linux, windows))`, so this was never Deck-specific. The presenter now publishes the version an overlay may size itself to as `SharedDevice::api_version`, and `SkiaOverlay::init` passes it instead of `None`. It is `min(what we declared, what the loader reports)`: taking the loader's number alone is this bug, and taking ours alone would break the mirror case, where a 1.1+ loader accepts our 1.3 `apiVersion` as intent even when it cannot deliver 1.3. Three unit tests pin both directions and the no-answer case. The three `API_VERSION_1_3` spellings in setup.rs now read the one constant, so the number the overlay is told can no longer drift from the number we asked for. Measured on the Deck (RADV VANGOGH, loader 1.4.321) with a standalone repro against the shipped crate -- the client build is not needed to see it: vkEnumerateInstanceVersion() -> 1.4.321 ; VkApplicationInfo -> 1.3.0 max_api_version = None => DirectContext NULL max_api_version = Some(1.3) => DirectContext OK Verified: cargo fmt --all --check; and in the pf-lxcheck2 x86_64 container, cargo build + cargo clippy --all-targets -- -D warnings for pf-console-ui and pf-presenter, plus cargo test -p pf-presenter (46 passed). Note that `cargo check -p pf-console-ui` on macOS is vacuous -- every mod in that crate is cfg(linux|windows), so it compiles nothing there.	2026-08-13 20:50:09 +02:00