enricobuehler
69728b6f4e
ci / bun-nix (pull_request) Successful in 23s
ci / web (pull_request) Successful in 1m11s
ci / docs-site (pull_request) Successful in 1m19s
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m33s
apple / swift (pull_request) Successful in 1m33s
apple / screenshots (pull_request) Skipped
ci / rust-arm64 (pull_request) Successful in 3m25s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m22s
android / android (pull_request) Successful in 4m41s
ci / rust (pull_request) Successful in 6m52s
A CachyOS / KDE Plasma 6.7.4 Wayland client with its 2560x1600@165 laptop panel at 150 % scaling negotiated 1706x1066 for "Native resolution" and streamed a visibly blurry image. Two independent defects, and they stack — which is why forcing the mode to 2560x1600 by hand did not fully fix it either. 1. `SDL_GetDesktopDisplayMode` reports a mode in SCREEN COORDINATES and hands the pixels-per-point ratio back separately as `pixel_density`. We read `m.w`/`m.h` raw. KDE advertises that panel as 1707x1067 points with a density of ~1.4997, `render_scale::apply` even-floors both odd axes, and 1706x1066 goes on the wire — exactly the mode in the reporter's handshake log. Multiplying by the density recovers 2560x1600 to the pixel, because SDL derives it as the output's exact pixels/points ratio. On X11 and Windows SDL never sets a density and `SDL_video.c` normalizes the unset 0.0 to 1.0, so this is inert there: the bug needed a compositor doing FRACTIONAL scaling. 2. The SDL window was created without `HIGH_PIXEL_DENSITY`, so the Wayland surface stayed at buffer scale 1 — the Vulkan swapchain was built at 1707x1067 and KWin upscaled it to the glass. Even a correct 2560x1600 stream was resampled down and then back up. The same flaw silently shrank "Match window", which asks the host for `size_in_pixels()`. The reporter's `SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1` workaround is this same fix applied from outside SDL, which is why it helped. The surrounding code was already written for pixels != points — the swapchain, match-window and pointer mapping all read `size_in_pixels()` while window-size persistence reads logical `size()` — so the flag only makes those two stop being the same number. `display_scale()` starts reporting 1.5 into a swapchain that is 1.5x larger, leaving the OSD the size it already was. Also closes a smaller hole on the way past: only an `Err` from SDL reached the 1920x1080 fallback, so a display that reported a 0x0 mode sent a 0x0 request. Verified on home-worker-5 (CachyOS — the reporter's distro, real SDL 3.4.14): `cargo clippy --all-targets -p pf-presenter -- -D warnings` clean and 18/18 pf-presenter tests pass, three of them new and pinned to the field-reported numbers.