August 2026 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR11737: ntdll: Infer the trap number in segv_handler() when the context lacks one.
by Nat Brown (＠natbro) Aug. 23, 2026

Aug. 23, 2026

An issue found while adding Apple Silicon macOS host support for building Proton (https://github.com/ValveSoftware/Proton/pull/10087) Proton's Wine version builds and then runs 64-bit and 32-bit versions of wine in order to create a base prefix as part of a redistributable package phase, all within a guest linux/amd64 container. 32-bit i386 processes translate with QEMU in this host context, while 64-bit x86_64 uses the host's Rosetta 2 translation system. It is likely but not confirmed that QEMU would similarly be used and 32-bit wine would fail to run when virtualizing linux/amd64 on linux/arm64 hardware. qemu-user synthesizes signal frames without filling in the trap number, leaving TRAP_sig() as -1. segv_handler() then falls through to the default case, logs "Got unexpected trap -1" and never services the fault, so page faults during 32-bit module loading surface as unhandled exceptions. Infer the trap from the delivered signal instead. Note that ERROR_sig() is unset for the same reason, so faults routed to TRAP_x86_PAGEFLT are classified as reads; that is sufficient to get through process startup but is not a complete emulation of the missing context. A different option to this hardening would be to work with the QEMU project to fill in its signal frames. This fix may be appropriate standalone hardening for Wine. Although discovered as a "build issue" it impacts many plausible layered and virtualized real uses of Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11737

3 2

[PATCH v2 0/2] MR11717: faudio: Initialize COM before creating the WMA decoder.
by Nello De Gregoris (＠bluechxin) Aug. 23, 2026

Aug. 23, 2026

Found while testing STEINS;GATE RE:BOOT (https://store.steampowered.com/app/4012810/STEINSGATE_REBOOT/) The visual novel voiceovers were not playing and every time one was supposed to play, the following showed up in logs: `err:ole:com_get_class_object apartment not initialised` Tracing this led me to `FAudio_WMADEC_init`, which runs CoCreateInstance on the thread the application called IXAudio2::CreateSourceVoice() from, with FAudio however never initializing COM on that path. That makes combase then reject the call with the decoder never being created. I believe most games don't run into this because Media Foundation is usually initialized before this code path is hit, which leaves a process-wide MTA in place. Since the voiceovers play correctly on Windows, handling it in FAudio seemed like the right call. -- v2: faudio: Initialize MTA in FAudio_PlatformAddRef(). xaudio2/tests: Test creating an xWMA source voice without COM. https://gitlab.winehq.org/wine/wine/-/merge_requests/11717

4 7

[PATCH 0/1] MR11736: ntdll: Keep reserved area bounds page aligned when avoiding 4GB wrap-around
by Nat Brown (＠natbro) Aug. 23, 2026

Aug. 23, 2026

A latent issue found in ntdll while adding Apple Silicon macOS host support for building Proton (https://github.com/ValveSoftware/Proton/pull/10087) Proton's Wine version builds and then runs 64-bit and 32-bit versions of wine in order to create a base prefix as part of a redistributable package phase, all within a guest linux/amd64 container. 32-bit i386 processes translate with QEMU in this host context, while 64-bit x86_64 uses the host's Rosetta 2 translation system. It is likely but not confirmed that QEMU would similarly be used and 32-bit wine would fail to run when virtualizing linux/amd64 on linux/arm64 hardware. mmap_add_reserved_area() and mmap_remove_reserved_area() trim a single byte when addr + size wraps to 0, which leaves an area whose end is 0xffffffff. alloc_virtual_heap() then derives its mapping address from that end and passes an unaligned address to anon_mmap_fixed(), tripping the alignment assertions added in d813ffc3557 (ntdll: Align virtual memory allocations to the host page size). Trim a whole page instead so the area bounds stay aligned. The wrap-around trim dates to 94d74b5fedf (2004), long before the alignment invariant existed. It is only reached when a reserved area ends exactly at 4GB, which requires mmap_init() to take the reserve_area( user_space_limit, 0 ) branch -- that is, when the initial stack is not near the top of the 32-bit address space. Native Linux and all other native x86 platforms place it near the top, so the branch is dead there; qemu-user lays out the guest address space itself and maps the stack around 0x40000000, making it reachable and aborting every 32-bit process at startup. Nothing verifies requested against recorded area bounds, and the top 64k allocation granularity block was already unusable due to the one-byte trim, so widening it to a page costs nothing allocatable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11736

2 1

[PATCH 0/1] MR11735: mfplat/tests: Remove todo on now succeeding test.
by Nikolay Sivov (＠nsivov) Aug. 23, 2026

Aug. 23, 2026

This one was fixed by d3d11 changes e980a920092d5f16aa75bb4a5c6d8a3bb8d32cfc. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11735

2 1

[PATCH v50 0/9] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) Aug. 23, 2026

Aug. 23, 2026

Follow-up of !2786, which appears to have been abandoned. Depends on !8182, !8575, !8578, !8863, !9831, !9835 # Execute minimal test case 1. checkout wine into \~/src/wine 2. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif 3. build into \~/src/wine-build 4. run ``` (cd ~/src/wine-build; \ WINEPREFIX=~/src/wine/.wine \ ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll \ -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` or without the wrapper and some imported wine debug channels enabled ``` (cd ~/src/wine-build; WINEPREFIX=~/src/wine/.wine \ WINEDEBUG=+file,+winsock \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` # How to debug wineserver Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected. The wineserver man page mentions that there is limited support to control wineserver debugging by using `WINEDEBUG=+server` ``` -d[n], --debug[=n] Set the debug level to n. 0 means no debugging information, 1 is the normal level, and 2 is for extra verbose debugging. If n is not specified, the default is 1. The debug output will be sent to stderr. wine(1) will automatically enable normal level debugging when starting wineserver if the +server option is set in the WINEDEBUG variable. ``` However, higher levels probably cannot be set in this way. # Problems with synchronized log output - The Windows test binary prints test failures to stdout (line-buffered or fully buffered). - Wine/Wineserver debug prints to stderr (unbuffered). When merged into a single stream (stderr+stdout), stdout lines get fragmented and interleaved between Wine/Wineserver trace messages., which looks like this: ``` 012c:trace:file:NtWriteFile (0xd,(nil),(nil),(nil),0x6afd40,0x4190bc,0x00000012,(nil),(nil)) [?25lsock.c[?25h012c:trace:file:NtWriteFile = SUCCESS (18) 0124:trace:file:NtDeviceIoControlFile (0x10,(nil),(nil),(nil),0x74ddd0,0x00504000,(nil),0x00000000,0x74ddcc,0x00000004)xts={} ) ``` Unfortunately, synchronized logs are important for analyzing processes. Combining synchronized strace and wine trace messages can be generated with ``` #!/bin/bash -x p=$PWD cd ~/src/wine-build WINEPREFIX=~/src/wine/.wine \ WINEDEBUG=+file,+winsock \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ stdbuf -o0 -eL strace -tt -f -o strace.log \ ./wine dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock 2>&1 | ts 'WINE %H:%M:%.S' > wine.log cat wine.log strace.log | grep -v 'write(\|read(\|rt_sigprocmask' | sort -k 2 > $p/trace.log ``` # How to debug a wine test case At https://gitlab.winehq.org/wine/wine/-/blob/master/tools/runtest#L151 there is mentioned a environment variable name `WINETEST_WRAPPER`, with which it may be possible to run gdb to debug test cases ``` (cd ~/src/wine-build; make -j10 ;\ WINETEST_WRAPPER="gdb --args" \ WINEPREFIX=~/src/wine/.wine \ ../wine/tools/runtest -P wine -T . -M ws2_32.dll \ -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) Reading symbols from ./wine... (gdb) set follow-fork-mode child (gdb) r current directory: 'Z:\home\ralf.habacker\src\wine-build' sock.c:14624: Test failed: test_afunix.sock: wrong attr ffffffff sock.c:14658: Test failed: test_afunix.sock: wrong family 0 sock.c:14693: Test failed: test_afunix.sock: wrong family 0 ... ``` or without the wrapper and some important debug channels enabled ``` (cd ~/src/wine-build; \ make -j10; \ WINEDEBUG=+file,+winsock \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ gdb --args ./wine dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` With this you can debug the wine application, but unfortunally not the windows api. # How to debug a wine test case (windows api) 1. After building wine install the binaries into a temporary location ``` make -C ~/src/wine-build install DESTDIR=~/src/wine-install ``` 2. run ``` (cd ../wine-build; \ WINEPREFIX=~/src/wine/.wine \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine programs/winedbg/i386-windows/winedbg.exe --gdb dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` Now let's look at the loaded shared libraries ``` Wine-gdb> info sharedlibrary From To Syms Read Shared Object Library 0xf7b39000 0xf7bff6e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine/.wine/drive_c/windows/system32/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine/.wine/drive_c/windows/system32/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine/.wine/drive_c/windows/system32/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine/.wine/drive_c/windows/system32/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine/.wine/drive_c/windows/system32/gdi32.dll 0x7a0b1000 0x7a0e48e8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` It is visible, that the unix variant of the shared libraries (ntdll.so) are read from the build dir and also the test case. The Windows part (\*.dll) is loaded from the wine prefix, so that these must be copied from the build directory initially and whenever changes are made. With this is possible to set breakpoints ``` Wine-gdb> b GetFileAttributesW@4 Breakpoint 1 at 0x7b5d3725: file ../wine/dlls/kernelbase/file.c, line 1665. Wine-gdb> c Continuing. Breakpoint 1, GetFileAttributesW@4 ( name=0x40fcfa <test_afunix+1434> L"\xec83\x8304\xfff8\x940f\x89c0\x247c\xf08\xc0b6\x44c7\x424\x1bbf\103\x489\xe824\x52e6\001\x44c7", <incomplete sequence \x824>) at ../wine/dlls/kernelbase/file.c:1665 1665 TRACE( "%s\n", debugstr_w(name) ); ``` # Followup By adding `WINESYSTEMDLLPATH=/home/user/src/wine-install/usr/local/lib/wine/i386-windows/` to the command line, some shared libraries are loaded directly from the build directory, so they do not need to be copied. ``` From To Syms Read Shared Object Library 0xf7eb2000 0xf7f786e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/gdi32.dll 0x79e31000 0x79e648e8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` Why this does not apply to all system libraries is currently unclear. It would help if at least ntdll.dll could be loaded from the build directory as it gets several changes here. -- v50: server: open bound AF_UNIX sockets as reparse points server: give AF_UNIX sockets their family before bind ntdll: report bound AF_UNIX sockets as reparse points server: harden the AF_UNIX socket path handling ws2_32: Add note in bind() for AF_UNIX sockets server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. ws2_32: Add support for AF_UNIX sockets. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

5 18

[PATCH 0/1] MR11734: include: Add IMFTimedText* definitions.
by Nikolay Sivov (＠nsivov) Aug. 23, 2026

Aug. 23, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60223 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11734

2 1

[PATCH 0/1] MR11733: wbemdisp: Avoid out-of-bounds read in objectpath_get_DisplayName.
by Bernhard Übelacker (＠bernhardu) Aug. 23, 2026

Aug. 23, 2026

Followup of 929b2a19cb. Found by ASan. In the call to `SysAllocStringLen` the copy does not stop at a terminating \0, therefore it reads beyond the end of the string constant. [ASan 32-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/297496#L2785) [ASan 64-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/297497#L2927) <details> <summary>ASan details</summary> ``` ==wbemdisp_test.exe==1468==ERROR: AddressSanitizer: global-buffer-overflow on address 0x784dbb14 at pc 0x78595252 bp 0x0022f630 sp 0x0022f1fc READ of size 138 at 0x784dbb14 thread T0 #0 0x78595251 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x799a9867 in SysAllocStringLen dlls/oleaut32/oleaut.c:358:9 #2 0x784ca369 in objectpath_get_DisplayName dlls/wbemdisp/locator.c:3717:17 #3 0x0040588f in ISWbemObjectPath_get_DisplayName /builds/bernhardu/wine/build64/include/wbemdisp.h:2170:12 #4 0x0040272f in test_ParseDisplayName dlls/wbemdisp/tests/wbemdisp.c:275:30 #5 0x00401021 in func_wbemdisp dlls/wbemdisp/tests/wbemdisp.c:663:5 #6 0x00408dd1 in run_test include/wine/test.h:780:5 #7 0x004088eb in main include/wine/test.h #8 0x0040a5c5 in mainCRTStartup dlls/msvcrt/crt_main.c:70:11 #9 0x7bcc381f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b82381f) #10 0x7be36c2a in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc46c2a) #11 0x7be3759a in call_thread_func dlls/ntdll/signal_i386.c:502:9 0x784dbb14 is located 44 bytes before global variable '"objectpath_put_DisplayName"' defined in 'dlls/wbemdisp/locator.c:3733' (0x784dbb40) of size 27 '"objectpath_put_DisplayName"' is ascii string 'objectpath_put_DisplayName' 0x784dbb14 is located 0 bytes after global variable 'L"winmgmts:"' defined in 'dlls/wbemdisp/locator.c:3717' (0x784dbb00) of size 20 SUMMARY: AddressSanitizer: global-buffer-overflow dlls/oleaut32/oleaut.c:358:9 in SysAllocStringLen ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11733

2 2

[PATCH 0/1] MR11732: msi: Pass deformated target to HANDLE_CustomType7 in ACTION_CustomAction.
by Gijs Vermeulen (＠gverm) Aug. 22, 2026

Aug. 22, 2026

Found while looking at [Bug 60221](https://bugs.winehq.org/show_bug.cgi?id=60221). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11732

2 1

Re: [PATCH v5 0/1] MR11667: win32u: Update menu bar item layout before tracking menu (fixes Reason 3.0 to 14 not opening the menu bar)
by Schroedingers Cat (＠Schroedingers-Cat) Aug. 22, 2026

Aug. 22, 2026

@rbernon could you take a look at this tiny bugfix PR? I made it now consist only of a single commit as requested. If there is anything else I can do to improve it for upstreaming, let me know! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11667#note_149606

1 0

[PATCH v74 0/6] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) Aug. 22, 2026

Aug. 22, 2026

wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl This merge request addresses: https://bugs.winehq.org/show_bug.cgi?id=45364 Frostpunk is very dark Very dark rendering issues for Frostpunk seem to match the same problem for Vulkan renderer for "Against the Storm": - https://bugs.winehq.org/show_bug.cgi?id=58632 - https://bugs.winehq.org/attachment.cgi?id=80656 Running both games with gl renderer seems to fix excessive darkness: - https://bugs.winehq.org/attachment.cgi?id=80654 - https://bugs.winehq.org/attachment.cgi?id=80690 Vulkan renderer seems to be missing SRGB conversion handling availiable for GL renderer. GL renderer can be forced to render darker the same as Vulkan by bypassing EXT_TEXTURE_SRGB support for ./dlls/wined3d/utils.c: ``` @@ -3133,7 +3146,7 @@ static BOOL init_format_texture_info(struct wined3d_adapter *adapter, struct win continue; copy_format(adapter, &srgb_format->f, &format->f); +#if 000 if (gl_info->supported[EXT_TEXTURE_SRGB] && !(adapter->d3d_info.wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL)) { @@ -3142,6 +3155,7 @@ static BOOL init_format_texture_info(struct wined3d_adapter *adapter, struct win format_set_caps(&srgb_format->f, WINED3D_FORMAT_CAP_SRGB_READ | WINED3D_FORMAT_CAP_SRGB_WRITE); query_internal_format(adapter, srgb_format, &format_texture_info[i], gl_info, TRUE); } +#endif } ``` This merge request patch allows Vulkan renderer to perform SRGB conversion for wined3d_swapchain_vk_select_vk_format() to mimic the GL capability. Changing VkSwapchainCreateInfoKHR imageColorSpace from VK_COLOR_SPACE_SRGB_NONLINEAR_KHR for `wined3d_swapchain_vk_create_vulkan_swapchain()` had no effect despite enabling VK_EXT_swapchain_colorspace for dlls/win32u/vulkan.c `convert_instance_create_info():` https://docs.vulkan.org/refpages/latest/refpages/source/VkColorSpaceKHR.html Therefore converting UNORM to SRGB was chosen similar to how the GL renderer seems to handle it: ``` static const struct wined3d_format_srgb_info format_srgb_info[] = { {WINED3DFMT_R8G8B8A8_UNORM_SRGB, WINED3DFMT_R8G8B8A8_UNORM}, {WINED3DFMT_BC1_UNORM_SRGB, WINED3DFMT_BC1_UNORM}, {WINED3DFMT_BC2_UNORM_SRGB, WINED3DFMT_BC2_UNORM}, {WINED3DFMT_BC3_UNORM_SRGB, WINED3DFMT_BC3_UNORM}, {WINED3DFMT_B8G8R8A8_UNORM_SRGB, WINED3DFMT_B8G8R8A8_UNORM}, {WINED3DFMT_B8G8R8X8_UNORM_SRGB, WINED3DFMT_B8G8R8X8_UNORM}, {WINED3DFMT_BC7_UNORM_SRGB, WINED3DFMT_BC7_UNORM}, }; ``` Its unclear whether SRGB conversion should always happen or only for particular games so the patch leaves the Vulkan renderer without SRGB conversion by default. Therefore the patch adds a new WINE_D3D_CONFIG flag named "vk_swap_srgb" to force the Vulkan renderer to perform SRGB conversion for the swapchain. By default vk_swap_srgb is set to FALSE or 0: `WINE_D3D_CONFIG=vk_swap_srgb=0,renderer=vulkan` To force vk_swap_srgb to TRUE or 1: `WINE_D3D_CONFIG=vk_swap_srgb=1,renderer=vulkan` For example, launching Frostpunk via the following after the patch fixes the dark rendering for Vulkan and appears brighter similar to the GL renderer: `WINEDEBUG=-all mangohud --dlsym WINE_D3D_CONFIG=csmt=0x1,renderer=vulkan,vk_swap_srgb=1 WINEPREFIX=/home/any/wine_stianlow_wow64_new_pfx ~/tmp/wine_stianlow_wow64_new_install/bin/wine /home/any/wine_stianlow_wow64_new_pfx/drive_c/GOG\ Games/Frostpunk/Frostpunk.exe` Some SRGB handling was added several years ago but not for mapping UNORM to SRGB that this patch adds: ``` 6f55c8d1c56 * wined3d: Use an sRGB fallback format for sRGB formats in wined3d_swapchain_vk_select_vk_format(). Author: Henri Verbeet <hverbeet(a)codeweavers.com> CommitDate: Wed Dec 9 16:29:28 2020 +0100 ``` If UNORM to SRGB should be enabled by default then this patch may be changed so that vk_swap_srgb defaults to TRUE. -- v74: wined3d: rotate wined3d_swapchain_rendertarget_view (MR-10567) wined3d: gl fix srgb texture2d_blt_fbo (MR-10567) wined3d: gl impl wined3d_swapchain_rendertarget_view (MR-10567) wined3d: vk impl wined3d_swapchain_rendertarget_view (MR-10567) wined3d: add wined3d_swapchain_rendertarget_view lists (MR-10567) wined3d/tests: todo srgb rtvs, unorm swapchain backbuf > 1 (MR-10567) https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

5 31