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

[PATCH 0/1] MR11279: oleview: Avoid heap-use-after-free when reloading (ASan).
by Bernhard Übelacker (＠bernhardu) June 29, 2026

June 29, 2026

This avoids two items with the same `tvis.item.lParam` getting added to the treeview. ASan got here triggered when the treeview gets cleared, because deletion of the second item wanted to access the already freed memory. <details> <summary>ASan details</summary> ```gdb ================================================================= ==432==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f3bd21e2284 at pc 0x00014000c19c bp 0x7ffffe20e1b0 sp 0x7ffffe20e1f8 READ of size 4 at 0x7f3bd21e2284 thread T0 #0 0x00014000c19b in TreeProc programs/oleview/tree.c:632 #1 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #2 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #3 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #4 0x6ffffd112760 in dispatch_send_message dlls/user32/message.c:567 #5 0x6ffffd1126e6 in SendMessageW dlls/user32/message.c:586 #6 0x6ffffdcf3db3 in TREEVIEW_SendRealNotify dlls/comctl32/treeview.c:517 #7 0x6ffffdcf7391 in TREEVIEW_SendTreeviewNotify dlls/comctl32/treeview.c:593 #8 0x6ffffdcf5a78 in TREEVIEW_RemoveItem dlls/comctl32/treeview.c:1496 #9 0x6ffffdcf6ec1 in TREEVIEW_RemoveAllChildren dlls/comctl32/treeview.c:1451 #10 0x6ffffdcf5a54 in TREEVIEW_RemoveItem dlls/comctl32/treeview.c:1494 #11 0x6ffffdcf6ec1 in TREEVIEW_RemoveAllChildren dlls/comctl32/treeview.c:1451 #12 0x6ffffdcf5434 in TREEVIEW_RemoveTree dlls/comctl32/treeview.c:1514 #13 0x6ffffdce8ae4 in TREEVIEW_DeleteItem dlls/comctl32/treeview.c:1533 #14 0x6ffffdce74cd in TREEVIEW_WindowProc dlls/comctl32/treeview.c:5718 #15 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #16 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #17 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #18 0x6ffffd112760 in dispatch_send_message dlls/user32/message.c:567 #19 0x6ffffd1126e6 in SendMessageW dlls/user32/message.c:586 #20 0x000140009640 in EmptyTree programs/oleview/tree.c:584 #21 0x00014000569d in MenuCommand programs/oleview/oleview.c #22 0x000140005218 in WndProc programs/oleview/oleview.c:453 #23 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #24 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #25 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #26 0x6ffffd128c5b in User32CallWinProc dlls/user32/winproc.c:826 #27 0x6fffffdc0cb2 in KiUserCallbackDispatcher (C:\windows\system32\ntdll.dll+0x170050cb2) #28 0x6ffffce3744b in NtUserTranslateAccelerator (C:\windows\system32\win32u.dll+0x18001744b) #29 0x000140004a2d in WinMain programs/oleview/oleview.c:558 #30 0x000140015c91 in main dlls/msvcrt/crt_winmain.c:61 0x7f3bd21e2284 is located 1540 bytes inside of 1552-byte region [0x7f3bd21e1c80,0x7f3bd21e2290) freed by thread T0 here: #0 0x6ffffe60d801 in free /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_malloc_win.cpp:78:3 #1 0x00014000c16a in TreeProc programs/oleview/tree.c:634 #2 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #3 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #4 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #5 0x6ffffd112760 in dispatch_send_message dlls/user32/message.c:567 #6 0x6ffffd1126e6 in SendMessageW dlls/user32/message.c:586 #7 0x6ffffdcf3db3 in TREEVIEW_SendRealNotify dlls/comctl32/treeview.c:517 #8 0x6ffffdcf7391 in TREEVIEW_SendTreeviewNotify dlls/comctl32/treeview.c:593 #9 0x6ffffdcf5a78 in TREEVIEW_RemoveItem dlls/comctl32/treeview.c:1496 #10 0x6ffffdcf6ec1 in TREEVIEW_RemoveAllChildren dlls/comctl32/treeview.c:1451 #11 0x6ffffdcf5a54 in TREEVIEW_RemoveItem dlls/comctl32/treeview.c:1494 #12 0x6ffffdcf6ec1 in TREEVIEW_RemoveAllChildren dlls/comctl32/treeview.c:1451 #13 0x6ffffdcf5434 in TREEVIEW_RemoveTree dlls/comctl32/treeview.c:1514 #14 0x6ffffdce8ae4 in TREEVIEW_DeleteItem dlls/comctl32/treeview.c:1533 #15 0x6ffffdce74cd in TREEVIEW_WindowProc dlls/comctl32/treeview.c:5718 #16 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #17 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #18 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #19 0x6ffffd112760 in dispatch_send_message dlls/user32/message.c:567 #20 0x6ffffd1126e6 in SendMessageW dlls/user32/message.c:586 #21 0x000140009640 in EmptyTree programs/oleview/tree.c:584 #22 0x00014000569d in MenuCommand programs/oleview/oleview.c #23 0x000140005218 in WndProc programs/oleview/oleview.c:453 #24 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #25 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #26 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #27 0x6ffffd128c5b in User32CallWinProc dlls/user32/winproc.c:826 previously allocated by thread T0 here: #0 0x6ffffe60da26 in calloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_malloc_win.cpp:98:3 #1 0x000140008dc7 in CreateITEM_INFO programs/oleview/tree.c:29 #2 0x000140009a32 in AddBaseEntries programs/oleview/tree.c:562 #3 0x000140009670 in AddTreeEx programs/oleview/tree.c:589 #4 0x00014000c022 in TreeProc programs/oleview/tree.c:612 #5 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #6 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #7 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #8 0x6ffffd128c5b in User32CallWinProc dlls/user32/winproc.c:826 #9 0x6fffffdc0cb2 in KiUserCallbackDispatcher (C:\windows\system32\ntdll.dll+0x170050cb2) #10 0x6ffffce326cb in NtUserCreateWindowEx (C:\windows\system32\win32u.dll+0x1800126cb) #11 0x6ffffd123512 in WIN_CreateWindowEx dlls/user32/win.c:391 #12 0x6ffffd1240ac in CreateWindowExW dlls/user32/win.c:461 #13 0x00014000bed1 in CreateTreeWindow programs/oleview/tree.c:661 #14 0x00014000518b in WndProc programs/oleview/oleview.c:448 #15 0x6ffffd1293c0 in WINPROC_wrapper dlls/user32/winproc.c:85 #16 0x6ffffd127f6c in call_window_proc dlls/user32/winproc.c:110 #17 0x6ffffd1280ce in dispatch_win_proc_params dlls/user32/winproc.c #18 0x6ffffd128c5b in User32CallWinProc dlls/user32/winproc.c:826 #19 0x6fffffdc0cb2 in KiUserCallbackDispatcher (C:\windows\system32\ntdll.dll+0x170050cb2) #20 0x6ffffce326cb in NtUserCreateWindowEx (C:\windows\system32\win32u.dll+0x1800126cb) #21 0x6ffffd123512 in WIN_CreateWindowEx dlls/user32/win.c:391 #22 0x6ffffd1240ac in CreateWindowExW dlls/user32/win.c:461 #23 0x000140004f2c in InitInstance programs/oleview/oleview.c:517 #24 0x0001400049a3 in WinMain programs/oleview/oleview.c:551 #25 0x000140015c91 in main dlls/msvcrt/crt_winmain.c:61 SUMMARY: AddressSanitizer: heap-use-after-free programs/oleview/tree.c:632 in TreeProc ASAN_OPTIONS="halt_on_error=0:allocator_may_return_null=1:strict_memcmp=0:windows_hook_rtl_allocators=1:detect_leaks=0:log_path=\"C:\\asan_\"" wine oleview gdb-multiarch -q --pid $(pidof 'C:\windows\system32\oleview.exe') set width 0 set pagination off set backtrace past-main handle SIGSEGV nostop noprint handle SIGUSR1 nostop noprint source tools/gdbunwind.py b ReportError b Die cont set osabi Windows bt (gdb) cont Continuing. [Detaching after fork from child process 2168041] Breakpoint 2, __sanitizer::Die() () at /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:51 warning: 51 /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp: Datei oder Verzeichnis nicht gefunden (gdb) set osabi Windows warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386:x64-32 (gdb) bt #0 __sanitizer::Die() () at /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:51 #1 0x00006ffffe616e73 in ~ScopedInErrorReport () at /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_report.cpp:221 #2 0x00006ffffe615980 in ReportGenericError () at /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_report.cpp:534 #3 0x00006ffffe617387 in __asan_report_load4 () at /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:130 #4 0x000000014000c19c in TreeProc (hWnd=<optimized out>, uMsg=<optimized out>, wParam=0, lParam=1152920405095219200) at programs/oleview/tree.c:632 #5 0x00006ffffd1293c1 in WINPROC_wrapper (proc=0x1000000000000001, hwnd=0x1, msg=0, wParam=18446742974197923840, lParam=140737456956832) at dlls/user32/winproc.c:85 #6 0x00006ffffd127f6d in call_window_proc (hwnd=0x770142, msg=78, wp=2001, lp=140737456956832, result=0x7ffffe20e3b8, arg=0x14000bf60 <TreeProc>) at dlls/user32/winproc.c:110 #7 0x00006ffffd1280cf in dispatch_win_proc_params (params=0x7ffffe20e488) at dlls/user32/winproc.c:712 #8 0x00006ffffd112761 in dispatch_send_message (params=0x7ffffe20e488, wparam=2001, lparam=140737456956832) at dlls/user32/message.c:567 #9 0x00006ffffd1126e7 in SendMessageW (hwnd=<optimized out>, msg=<optimized out>, wparam=2001, lparam=140737456956832) at dlls/user32/message.c:586 #10 0x00006ffffdcf3db4 in TREEVIEW_SendRealNotify (infoPtr=<optimized out>, code=4294966838, hdr=0x7ffffe20e5a0) at dlls/comctl32/treeview.c:517 #11 0x00006ffffdcf7392 in TREEVIEW_SendTreeviewNotify (infoPtr=<optimized out>, code=<optimized out>, action=<optimized out>, mask=<optimized out>, oldItem=<optimized out>, newItem=<optimized out>) at dlls/comctl32/treeview.c:593 #12 0x00006ffffdcf5a79 in TREEVIEW_RemoveItem (infoPtr=0x7ffffe7b3f00, item=0x7ffffe7b4ee0) at dlls/comctl32/treeview.c:1496 #13 0x00006ffffdcf6ec2 in TREEVIEW_RemoveAllChildren (infoPtr=0x7ffffe7b3f00, parentItem=0x7ffffe7b4df0) at dlls/comctl32/treeview.c:1451 #14 0x00006ffffdcf5a55 in TREEVIEW_RemoveItem (infoPtr=0x7ffffe7b3f00, item=0x7ffffe7b4df0) at dlls/comctl32/treeview.c:1494 #15 0x00006ffffdcf6ec2 in TREEVIEW_RemoveAllChildren (infoPtr=0x7ffffe7b3f00, parentItem=0x7ffffe7b4280) at dlls/comctl32/treeview.c:1451 #16 0x00006ffffdcf5435 in TREEVIEW_RemoveTree (infoPtr=0x7ffffe7b3f00) at dlls/comctl32/treeview.c:1514 #17 0x00006ffffdce8ae5 in TREEVIEW_DeleteItem (infoPtr=0x7ffffe7b3f00, item=<optimized out>) at dlls/comctl32/treeview.c:1533 #18 0x00006ffffdce74ce in TREEVIEW_WindowProc (hwnd=0xc016a, uMsg=4353, wParam=0, lParam=-65536) at dlls/comctl32/treeview.c:5718 #19 0x00006ffffd1293c1 in WINPROC_wrapper (proc=0x1000000000000001, hwnd=0x1, msg=0, wParam=18446742974197923840, lParam=-65536) at dlls/user32/winproc.c:85 #20 0x00006ffffd127f6d in call_window_proc (hwnd=0xc016a, msg=4353, wp=0, lp=-65536, result=0x7ffffe20ead8, arg=0x6ffffdce6ee0 <TREEVIEW_WindowProc>) at dlls/user32/winproc.c:110 #21 0x00006ffffd1280cf in dispatch_win_proc_params (params=0x7ffffe20eba8) at dlls/user32/winproc.c:712 #22 0x00006ffffd112761 in dispatch_send_message (params=0x7ffffe20eba8, wparam=0, lparam=-65536) at dlls/user32/message.c:567 #23 0x00006ffffd1126e7 in SendMessageW (hwnd=<optimized out>, msg=<optimized out>, wparam=0, lparam=-65536) at dlls/user32/message.c:586 #24 0x0000000140009641 in EmptyTree () at programs/oleview/tree.c:584 #25 0x000000014000569e in MenuCommand (wParam=<optimized out>, hWnd=<optimized out>) at programs/oleview/oleview.c:313 #26 0x0000000140005219 in WndProc (hWnd=0x0, uMsg=<optimized out>, wParam=0, lParam=1152920405095219200) at programs/oleview/oleview.c:453 #27 0x00006ffffd1293c1 in WINPROC_wrapper (proc=0x1000000000000001, hwnd=0x1, msg=0, wParam=18446742974197923840, lParam=0) at dlls/user32/winproc.c:85 #28 0x00006ffffd127f6d in call_window_proc (hwnd=0x3016e, msg=273, wp=65660, lp=0, result=0x7ffffe20fc28, arg=0x140005120 <WndProc>) at dlls/user32/winproc.c:110 #29 0x00006ffffd1280cf in dispatch_win_proc_params (params=0x7ffffe20fd08) at dlls/user32/winproc.c:712 #30 0x00006ffffd128c5c in User32CallWinProc (args=<optimized out>, size=<optimized out>) at dlls/user32/winproc.c:826 #31 0x00006fffffdc0cb3 in KiUserCallbackDispatcher () from dlls/ntdll/x86_64-windows/ntdll.dll #32 0x00006ffffce3744c in NtUserTranslateAccelerator () from dlls/win32u/x86_64-windows/win32u.dll #33 0x0000000140004a2e in WinMain (hInst=<optimized out>, hPrevInst=<optimized out>, lpCmdLine=<optimized out>, nCmdShow=<optimized out>) at programs/oleview/oleview.c:558 #34 0x0000000140015c92 in main (argc=<optimized out>, argv=<optimized out>) at dlls/msvcrt/crt_winmain.c:61 (gdb) ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11279

2 1

[PATCH 0/1] MR11266: dwrite: Fix Miscellaneous Symbols font fallback.
by Ziqing Hui (＠zhui) June 29, 2026

June 29, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11266

3 2

[PATCH 0/1] MR11275: server: Fix a memory leak in d3dkmt_share_objects.
by Zhiyi Zhang (＠zhiyi) June 29, 2026

June 29, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11275

3 2

[PATCH v2 0/1] MR11278: vbscript: Count a bare carriage return as a line break in error reporting.
by Francis De Brabandere (＠francisdb) June 29, 2026

June 29, 2026

-- v2: vbscript: Report the correct error line for scripts using carriage-return line endings. https://gitlab.winehq.org/wine/wine/-/merge_requests/11278

2 1

[PATCH 0/1] MR8779: kernel32: Add stub for PssQuerySnapshot.
by Louis Lenders (＠xe) June 29, 2026

June 29, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58610 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8779

4 4

[PATCH v51 0/11] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) June 28, 2026

June 28, 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. -- v51: wined3d/tests: fix SRGB RTV UNORM swapchain backbuffers > 1 for d3d10/11 MR-10567 wined3d: gl fix texture2d_blt_fbo SRGB handling for MR-10567 wined3d: use wined3d_swapchain_rendertarget_view_gl_rotate for MR-10567 wined3d: impl wined3d_swapchain_rendertarget_view_gl for MR-10567 https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

2 11

Re: [PATCH v50 0/11] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) June 28, 2026

June 28, 2026

> This is hard to read and could probably do with quite a lot of splitting > Tracking the list of swapchain views, while not doing anything with them yet, can be its own commit. > GL and Vulkan rotate implementations should ideally be separated. Commits have been split. Please let me know if they should be adjusted more. > D3D11_FORMAT_SUPPORT_BACK_BUFFER_CAST implementation can be its own commit It also should not use a fixed list of formats, and should live in wined3d like all the other format flags. D3D11_FORMAT_SUPPORT_BACK_BUFFER_CAST now handled along with the other format flags for `ID3D11Device_CheckFormatSupport > D3D11_FORMAT_SUPPORT_BACK_BUFFER_CAST validation similarly can be its own commit, and also should live in wined3d. Actually, you seem to unnecessarily have it in both places? `wined3d_check_device_format` is called directly now instead of via `ID3D11Device_CheckFormatSupport` for less `d3d_rendertarget_view_init` overhead which handles the validation specifically for d3d10/11 all in one call. `ID3D11Device_CheckFormatSupport` changes are technically no longer needed to support the fix but included with patchset anyway since it may be needed to fix other apps. > I would not use the fixed array size of 29; just allocate it dynamically instead the same as we do for the actual list of backbuffers. With that done, wined3d_swapchain_rendertarget_view_gl is fairly unnecessary; it's just a single pointer that can be put directly in wined3d_rendertarget_view like the others. `wined3d_swapchain_rendertarget_view_gl` and vk have been changed as list structs instead of wrappers of `wined3d_rendertarget_view_gl` and initialized based on `view_gl->bo_user.entry`. > Disabling GL_FRAMEBUFFER_SRGB on swapchain blit is still wrong, as Henri said. (Moving it back "to fix test failures" is not correct; you need to understand why it should be there.) And that should be its own commit; it's not related to the rest of this. GL_FRAMEBUFFER_SRGB has been moved back to `texture2d_blt_fbo` with a condition for `resolve_format` `WINED3D_FORMAT_CAP_SRGB_WRITE`. Unclear if this is actually correct but it fixes tests and Frostpunk. @zfigura originally mentioned WINED3D_FORMAT_CAP_SRGB_WRITE may be a discrepancy before I discovered lack of backbuffers support was a wider problem so it seems to come full circle. Some extra vulkan/damavand tests fail locally despite wine server tests passing. Is there a way to get wine server to also test vulkan? Vulkan may have bugs that this patch exposes similar to GL_FRAMEBUFFER_SRGB bug. I think this merge is ready for another review while vulkan fails are addressed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_144391

1 0

[PATCH v49 0/11] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) June 28, 2026

June 28, 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. -- v49: wined3d/tests: fix SRGB RTV UNORM swapchain backbuffers > 1 for d3d10/11 MR-10567 wined3d: gl fix texture2d_blt_fbo SRGB handling for MR-10567 wined3d: use wined3d_swapchain_rendertarget_view_gl_rotate for MR-10567 wined3d: impl wined3d_swapchain_rendertarget_view_gl for MR-10567 wined3d: use wined3d_swapchain_rendertarget_view_vk_rotate for MR-10567 wined3d: impl wined3d_swapchain_rendertarget_view_vk for MR-10567 wined3d: add wined3d_swapchain_rendertarget_view for MR-10567 wined3d: use impl D3D BACK_BUFFER_CAST for MR-10567 wined3d: impl D3D BACK_BUFFER_CAST for MR-10567 wined3d: add swapchain_from_resource for MR-10567 wined3d/tests: todo SRGB RTV UNORM swapchain backbuffers > 1 for d3d10/11 MR-10567 https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

2 11

[PATCH v48 0/2] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) June 28, 2026

June 28, 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. -- v48: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11 https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

2 2

[PATCH v46 0/2] MR10567: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11
by Stian Low (＠stianlow) June 28, 2026

June 28, 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. -- v46: wined3d: fix SRGB RTV fail for UNORM swapchain backbuffers > 1 for d3d10/11 https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

2 2