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

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

June 27, 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. -- v34: 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 0/4] MR11267: ntdll: Use getauxval(AT_HWCAP) to detect ARM/ARM64 processor features
by Brendan Shanks (＠bshanks) June 26, 2026

June 26, 2026

The motivation here is to simplify processor feature detection on ARM/ARM64 by using `getauxval(AT_HWCAP)` instead of parsing `/proc/cpuinfo` (which is meant for human readability). Corresponding `FEAT_` strings for each feature are also included for use on macOS. And FreeBSD uses the same HWCAP_ constants as Linux, in the future this should work there with minor changes. @mstorsjo, this should build with fairly old headers too. The flags we use on ARM32 are all quite old, so I don’t think there’s a need to define them. For ARM64 I’m defining almost everything we use (`AT_HWCAP2`, and everything newer than the earliest `HWCAP_` flags). Let me know if additional defines are needed. References: - For most ARM64 PF_ features, Microsoft’s [documentation for `IsProcessorFeaturePresent()`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent) documents the corresponding ARM64 `FEAT_`. - ARM’s own documentation is clunky, but googling for a `FEAT_` string will get you ARM’s documentation and what registers can be used to identify it (i.e. for `FEAT_SHA3`, [the documentation](https://developer.arm.com/documentation/109697/2026_03/Featu… says that it sets `ID_AA64ISAR0_EL1.SHA3`. - The Linux kernel documents which `HWCAP_` constant corresponds to various register values: https://docs.kernel.org/arch/arm64/elf_hwcaps.html -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11267

2 4

Re: [PATCH v2 0/1] MR11244: wbemprox: Use device instance id for pnpdevice_id in get_display_adapters().
by Paul Gofman (＠gofman) June 26, 2026

June 26, 2026

Well, before those changes the string was also including (faked) additional bus info with '&', which was making the string fully compatible but not matching instance id from setupapi (a potential source of bugs on its own). If we hit something requiring stricter Windows string match with bus id the right way will be to add that to GPU instance ids in win32u. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11244#note_144329

1 0

Re: [PATCH v2 0/1] MR11244: wbemprox: Use device instance id for pnpdevice_id in get_display_adapters().
by Tim Clem (＠tclem) June 26, 2026

June 26, 2026

Thanks for catching that. For what it's worth, the EA app still seems satisfied with this change (which was the motivation for using setupapi in !9035). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11244#note_144327

1 0

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

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

3 5

[PATCH 0/3] MR11260: ws2_32,qcap,http: Fix -Wunused-but-set-global warnings.
by Jacek Caban (＠jacek) June 26, 2026

June 26, 2026

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

3 4

[PATCH 0/8] MR11263: ntoskrnl.exe: Various fixes around PDO behavior.
by Connor McAdams (＠cmcadams) June 26, 2026

June 26, 2026

This series of patches are prerequisites for changing how device instance IDs (and eventually container IDs) are assigned by the PnP manager. MR !8015 touched the same area, this should fix the same bug that MR intended to address. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11263

3 12

[PATCH v2 0/2] MR11264: Hardware Device IDs from CoreAudio USB devices
by Aric Stewart (＠aricstewart) June 26, 2026

June 26, 2026

-- v2: mmdevapi: Propagate the hardware Device_InstanceId coreaudio: Report USB device PKEY_Device_InstanceId https://gitlab.winehq.org/wine/wine/-/merge_requests/11264

2 2

[PATCH v2 0/6] MR11231: dxgi: Create a windowed swapchain instead when the fullscreen mode scanline order or scaling is invalid.
by Zhiyi Zhang (＠zhiyi) June 26, 2026

June 26, 2026

-- v2: dxgi: Refuse to enter fullscreen when the fullscreen mode scanline order or scaling is invalid. dxgi: Create a windowed swapchain instead when the fullscreen mode scanline order or scaling is invalid. dxgi: Report the DXGI_SWAP_CHAIN_FULLSCREEN_DESC used for creating a D3D11 swapchain. dxgi/tests: Test creating a fullscreen swapchain with an invalid scanline order or scaling. https://gitlab.winehq.org/wine/wine/-/merge_requests/11231

2 7

[PATCH v5 0/1] MR10809: comctl32: Fix VARHEIGHT rebar scaling when cyIntegral == 0
by Feli Rippmann (＠Feli) June 26, 2026

June 26, 2026

This is a test and fix for an edge case in the rebar component where `cyChild` is set to a larger value than `cyMaxChild` while `cyIntegral` is exactly 0 on a VARIABLEHEIGHT rebar. On Windows, at least the two Win11 machines I have acces to, the WinAPI seems to clamp the value to `cyMaxChild` so the test passes. On Wine, it does not clamp the value and the test fails, but passes with the fix. Specifically, Wine's behaviour results in the program EffectsEd3 from the modding tools of Call of Duty: World at War sizing its rebar height incorrectly, taking over the whole window and making the program unusable. With the fix, this is no longer the case and the program becomes usable. ![EffectsEd3 before Patch.png](/uploads/496a3bfe57dd15fb7e98c9a18073f5fb/EffectsEd3_before_Patch.png){width=255 height=189} - ![EffectsEd3 after Patch.png](/uploads/f57ac713c373b3063142f4e45b209a93/EffectsEd3_after_Patch.png){width=351 height=185} -- v5: comctl32: Clamp rebar height to cyMaxChild when cyIntegral == 0 too https://gitlab.winehq.org/wine/wine/-/merge_requests/10809

3 3