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

[PATCH v28 0/1] MR10393: vbscript: Probe top-level declared names against the host dispatch.
by Francis De Brabandere (＠francisdb) May 9, 2026

May 9, 2026

Match native VBScript's pattern of probing top-level declared names against an `ISVISIBLE` named item's host `IDispatch` at parse time, and keep the probe IDispatch slot independent of the runtime cache. Why - **Wire-level compatibility.** Hosts that observe `GetIDsOfNames` calls see the same pattern they get on native. The probe result is discarded - it doesn't change shadowing - but the host gets notified of declared names. - **Correctness with rotating hosts.** Wine previously had a single `IDispatch` slot per named item; a Dim parse overwrote the runtime cache, misrouting subsequent qualified access. The patch keeps the probe slot (`dim_probe_disp`) separate. What's in it - Probe pass in `exec_global_code` for visible items, in native order: Subs/Functions -> Classes -> explicit Dims -> implicit declarations from bare top-level assignments. - Cross-parse deduplication: a name is probed at most once per named item across the script lifetime. - Two-slot independence; probe slot reused as runtime cache when no separate runtime fetch has happened yet. - Lazy runtime fetch via `ensure_named_item_disp`. Known divergence (follow-up) When an implicit-decl name is later read as RHS (`a = 1; b = a`), Wine still triggers one extra runtime `GetIDsOfNames` that native avoids. Native pre-creates implicit decls during parse; matching that needs compiler changes. Verified against native VBScript 5.812 with a raw-IDispatch probe harness. -- v28: vbscript: Probe top-level declared names against the host dispatch. https://gitlab.winehq.org/wine/wine/-/merge_requests/10393

2 1

[PATCH 0/1] MR10851: Draft: vbscript: Implement IDispatch::GetTypeInfo for class instances via ICreateTypeLib2.
by Francis De Brabandere (＠francisdb) May 9, 2026

May 9, 2026

Alternative to !10461 Build a TKIND_DISPATCH ITypeInfo for each class instance using oleaut32's ICreateTypeLib2 / ICreateTypeInfo API rather than hand-rolling the 22 ITypeInfo methods. The class name comes back from GetDocumentation(MEMBERID_NIL), public funcs and Dim'd properties are exposed via GetFuncDesc/GetVarDesc, and inherited typeinfo machinery (GetContainingTypeLib etc.) works for free. A few assertions are marked todo_wine because Wine's oleaut32 CreateTypeLib2 currently: - adds 7 phantom inherited IDispatch methods to TKIND_DISPATCH typeinfos, inflating cFuncs and zeroing cImplTypes; - returns E_INVALIDARG instead of TYPE_E_BADMODULEKIND from CreateInstance; - doesn't zero the out-parameter on AddressOfMember failure; - returns a reftype from GetRefTypeOfImplType that GetRefTypeInfo can't resolve. The test passes 0/0 on native Windows VBScript and 0/8 on Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10851

2 1

[PATCH v4 0/3] MR10567: wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB...
by Stian Low (＠stianlow) May 9, 2026

May 9, 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. -- v4: wined3d: fix vk swapchain rendering too dark by supporting rtvs for swapchain back_buffers > 1 Revert "wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl" wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

2 3

[PATCH v3 0/27] MR10567: wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB...
by Stian Low (＠stianlow) May 9, 2026

May 9, 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. -- v3: vbscript/tests: Cover top-level Const behavior. vbscript: Delegate do_icall is_call branch to variant_call. vbscript: Raise illegal-func-call on empty parens of class variant property. vbscript/tests: Cover empty parens on properties, Dim variables, and arrays. ws2_32: Exclude not found and loopback addresses in get_local_ips() if others present. ws2_32/tests: Properly check for loopback address in test_gethostbyname(). This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

1 0

[PATCH 0/3] MR10849: Mix shadow var
by Alistair Leslie-Hughes (＠alesliehughes) May 9, 2026

May 9, 2026

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

2 3

[PATCH 0/1] MR10848: winewayland.drv: Add alpha-modifier-v1 protocol to support change alpha by...
by JiangYi Chen (＠meshine) May 9, 2026

May 9, 2026

winewayland.drv: Add alpha-modifier-v1 protocol to support change alpha by WAYLAND_SetLayeredWindowAttributes. The attachment is the test source code on Windows and the corresponding generated test program. [test-layered-alpha.cpp](/uploads/dba6d38e8990978d4bde562011c85995/test-layered-alpha.cpp) [test-layered-alpha.exe](/uploads/bba6c165533d56ca85af9d461e488b03/test-layered-alpha.exe) The test program runs as shown in the figure below. ![test](/uploads/d862049eaeda3c57265b648a529f4af8/test.bmp){width=505 height=543} The purpose of the patch is that when adjusting the Alpha slider in the figure, the transparency of the window changes accordingly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10848

2 1

[PATCH 0/1] MR10847: preloader: Account for ld.so stack usage when reserving.
by Yuxuan Shui (＠yshui) May 8, 2026

May 8, 2026

preloader will skip reserving a memory regioning if it overlaps with the arguments. Because the stack grows downwards from the arguments, the reserve region would have overlapped the stack had it not been skipped. Problem is, this check does not account for the stack usage of ld.so. Some ld.so functions such as [1] has relatively big stack frames. If the arguments array is *just* above a reserve region, the overlap check will pass, the region will be reserved. Then after the control flow has been passed to ld.so, it will crash after the stack frame grows into the reservation. [1]: https://elixir.bootlin.com/glibc/glibc-2.43.9000/source/elf/rtld.c#L855 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10847

2 2

[PATCH v2 0/21] MR10567: wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB...
by Stian Low (＠stianlow) May 8, 2026

May 8, 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. -- v2: wined3d: fix vk swapchain rendering too dark by supporting rtvs for swapchain back_buffers > 1 vbscript: Implement DateDiff built-in function. vbscript: Support assignment to chained array index expressions. vbscript: Coerce VT_EMPTY operands before Var* calls. vbscript/tests: Cover Dim/Sub shadowing of host members. server: Store the client page size in the process struct. msxml3/tests: Add some tests for selecting from detached nodes. msxml3/tests: Add a basic test for replaceChild() on attributes. msxml3/tests: Remove some refcount tests. msxml3: Handle baseName property for entity references. kernel32/tests: Avoid unused variables. advapi32/tests: Remove unused variable. msv1_0: Handle SEC_WINNT_AUTH_IDENTITY_EX. winhttp: Always queue async writes. win32u: Support OBJID_CLASSNAMEIDX in scrollbar controls. mf/session: Support asynchronous transforms. mf/tests: Add asynchronous transform tests. ntdll: Use debugstr_wn instead of debugstr_w in nt_to_unix_file_name. kernelbase: Run conhost.exe from c:\windows\system32 directory. Revert "wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl" wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

1 3

[PATCH v4 0/1] MR10830: winewayland: Use wp_pointer_warp_v1 for SetCursorPos when available.
by Zakaria HABRI (＠zakissimo) May 8, 2026

May 8, 2026

The existing SetCursorPos implementation abuses zwp_locked_pointer_v1's set_cursor_position_hint side-effect: it briefly locks the pointer, sets the position hint, then unlocks. The compositor clamps position hints to locked-surface bounds, so warps to coordinates outside that area are silently dropped, and the lock/unlock cycle has subtle timing and side-effect issues. wp_pointer_warp_v1 is a staging protocol added in wayland-protocols 1.45 (June 2025) that provides a direct cursor-warp primitive without requiring pointer locking. KWin \>=6.4, Mutter \>=49, and wlroots \>=0.19 already implement it on the compositor side. This MR adds support to winewayland.drv: when the compositor advertises the global and we have a recent enter serial, the new path is used; otherwise we fall back to the existing lock/hint workaround. ## Testing - KWin 6.6.4 (Plasma Wayland): protocol advertised, new path fires (verified via `WINEDEBUG=+waylanddrv` showing the new `warp_pointer hwnd=...` TRACE). - niri 26.04 (no protocol support): fallback path fires unchanged. - Fallback else-branch is byte-equivalent to upstream master (only `pending_warp = FALSE` was hoisted out of the if-block). ## References - Protocol spec: https://wayland.app/protocols/pointer-warp-v1 - Existing workaround MR: !7353 (cc @atticf — thanks for the original workaround that this MR complements) - SDL adoption: https://github.com/libsdl-org/SDL/pull/10922 -- v4: winewayland: Use wp_pointer_warp_v1 for SetCursorPos when available. https://gitlab.winehq.org/wine/wine/-/merge_requests/10830

2 1

Re: [PATCH v3 0/1] MR10830: winewayland: Use wp_pointer_warp_v1 for SetCursorPos when available.
by Zakaria HABRI (＠zakissimo) May 8, 2026

May 8, 2026

I saw both styles in the same file (`wayland_surface_coords_from_window` at line 1063 uses first-arg-on-same-line, `zwp_locked_pointer_v1_set_cursor_position_hint` just below uses open-paren-on-own-line). I'm not really attached either way — pushed an update aligning with the latter. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10830#note_139266

1 0