fix(vk): Linux/Wayland: take an sRGB surface format for the swapchain #679

Closed
t0masz407 wants to merge 1 commit from fix/wayland-swapchain-colorspace into main
t0masz407 commented 2026-11-08 16:43:25 +00:00 (Migrated from github.com)

What

create_swapchain (gpu/vk/vk_main.cpp) kept the last B8G8R8A8_UNORM / R8G8B8A8_UNORM surface format, whatever its colour space. It now takes the first of them in VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.

Why

RADV's Wayland WSI lists every surface format twice: first in SRGB_NONLINEAR_KHR, then again in COLOR_SPACE_PASS_THROUGH_EXT (vulkaninfo, RX 7900 XTX, Mesa 26.2.6). With SDL_VIDEODRIVER=wayland the loop therefore ended on R8G8B8A8_UNORM + PASS_THROUGH_EXT, and the compositor showed the picture without colour management: a grey, washed-out image on an HDR desktop (Hyprland 0.56, wp_color_manager_v1). X11/XWayland and Windows only list sRGB entries, which is why it never showed there or on NVIDIA/Windows. Nothing changes on those paths: the chosen format is the same one as before.

Tested

RX 7900 XTX, RADV (Mesa 26.2.6), NixOS, Hyprland with an HDR desktop, Kokiri Forest, build a598b9f + this change (+ #448):

picture present per frame fps (presents, frame generation 2x)
XWayland (default) normal 8.0 ms 43
native Wayland, before grey – –
native Wayland, with this fix same colours as XWayland 5.8 ms 47.6

tests/test_swapchain_colorspace.py checks the choice (fails on main, passes here) and is wired into source-regressions.yml.

🤖 Generated with Claude Code

## What `create_swapchain` (`gpu/vk/vk_main.cpp`) kept the **last** `B8G8R8A8_UNORM` / `R8G8B8A8_UNORM` surface format, whatever its colour space. It now takes the **first** of them in `VK_COLOR_SPACE_SRGB_NONLINEAR_KHR`. ## Why RADV's Wayland WSI lists every surface format twice: first in `SRGB_NONLINEAR_KHR`, then again in `COLOR_SPACE_PASS_THROUGH_EXT` (vulkaninfo, RX 7900 XTX, Mesa 26.2.6). With `SDL_VIDEODRIVER=wayland` the loop therefore ended on `R8G8B8A8_UNORM` + `PASS_THROUGH_EXT`, and the compositor showed the picture without colour management: a grey, washed-out image on an HDR desktop (Hyprland 0.56, `wp_color_manager_v1`). X11/XWayland and Windows only list sRGB entries, which is why it never showed there or on NVIDIA/Windows. Nothing changes on those paths: the chosen format is the same one as before. ## Tested RX 7900 XTX, RADV (Mesa 26.2.6), NixOS, Hyprland with an HDR desktop, Kokiri Forest, build `a598b9f` + this change (+ #448): | | picture | `present` per frame | fps (presents, frame generation 2x) | |---|---|---|---| | XWayland (default) | normal | 8.0 ms | 43 | | native Wayland, before | grey | – | – | | native Wayland, with this fix | same colours as XWayland | 5.8 ms | 47.6 | `tests/test_swapchain_colorspace.py` checks the choice (fails on `main`, passes here) and is wired into `source-regressions.yml`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
NotRexed commented 2026-11-08 23:21:36 +00:00 (Migrated from github.com)

Thanks for the clear write-up! This conflicts with main now; could you rebase it onto main?

Thanks for the clear write-up! This conflicts with main now; could you rebase it onto main?
NotRexed commented 2026-11-09 05:29:52 +00:00 (Migrated from github.com)

Closing to keep the queue clear — please rebase on current main and reopen; thanks!

Closing to keep the queue clear — please rebase on current main and reopen; thanks!
Commenting is not possible because the repository is archived.
No description provided.