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

Closed

t0masz407 wants to merge 1 commit from fix/wayland-swapchain-colorspace into main

t0masz407 commented

2026-11-09 11:33:19 +00:00

(Migrated from github.com)

Supersedes #679, which was closed for a conflict with main: rebased onto current main, the fix is unchanged.

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

Also run on v2.0.7 with this change, native Wayland on the same desktop: colours as on XWayland.

tests/test_swapchain_colorspace.py checks the choice (fails on main, passes here); tests/run_all.py picks it up.

🤖 Generated with Claude Code

Supersedes #679, which was closed for a conflict with main: rebased onto current main, the fix is unchanged. ## 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 | Also run on v2.0.7 with this change, native Wayland on the same desktop: colours as on XWayland. `tests/test_swapchain_colorspace.py` checks the choice (fails on `main`, passes here); `tests/run_all.py` picks it up. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

t0masz407 commented

2026-11-09 12:22:15 +00:00

(Migrated from github.com)