- Wine-GitLab - list.winehq.org

[PATCH 0/5] MR11342: winewayland: Reuse a single client surface for vulkan.
by Etaash Mathamsetty (＠etaash.mathamsetty) Aug. 20, 2026

Aug. 20, 2026

This may seem unnecessary, but it is required for many Windows Vulkan apps to function correctly on Wayland when using dmabuf in certain situations (like direct scanout). Here is the mesa vulkan wayland WSI source code for reference: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_com… I'll use the examples of Doom Eternal and Wolfenstein Youngblood to show where problems arise: Doom Eternal: 1. VkCreateWin32SurfaceKHR -> create new client surface -> create new wl_surface -> VkCreateWaylandSurfaceKHR -> WSI queries and stores the set of default DMABUF modifiers -> create the per surface dmabuf feedback (but the compositor has no idea where the wl_surface will be placed, so it can't send us any modifiers yet) 3. VkCreateSwapchainKHR 4. [Do some presents] 5. Swapchain becomes suboptimal (because the compositor sent the modifiers for the wl_surface, which end up being different than the default one) 6. VkDestroySwapchainKHR 7. VkCreateSurfaceKHR: The same thing happens as in step 1. This leads us to have default dmabuf modifiers again. (Note: it leaks VkSurface. That is the primary difference compared to Wolfenstein.) 9. VkCreateSwapchainKHR (old swapchain is not passed in) 10. ... and we eventually get another suboptimal since the per wl_surface dmabuf modifiers arrived, which causes the entire process to repeat infinitely. Wolfenstein Youngblood: 1. VkCreateWin32SurfaceKHR -> create new client surface -> create new wl_surface -> VkCreateWaylandSurfaceKHR -> WSI queries and stores the set of default DMABUF modifiers 3. VkCreateSwapchainKHR 4. [Do some presents] 5. Swapchain becomes suboptimal (because the compositor sent the modifiers for the wl_surface, which end up being different from the default one) 6. VkDestroySwapchainKHR 7. VkDestroySurfaceKHR -> destroys the client surface -> destroys the wl_surface from step 1 8. VkCreateSurfaceKHR: The same thing happens as in step 1. This leads us to have default dmabuf modifiers again. 9. VkCreateSwapchainKHR (old swapchain is not passed in) 10. ... and we eventually get another suboptimal since the per wl_surface dmabuf modifiers arrived, which causes the entire process to repeat infinitely. Another non-obvious important piece of information: if we use the same wl_surface for all the VkSurfaces for the same hwnd, then the compositor can remember and send the correct surface feedback much earlier, avoiding the problem. (I believe it is this roundtrip that helps: https://gitlab.freedesktop.org/mesa/mesa/-/blob/2046b79f2f043502a44bd86b64f…) Therefore, to fix the above two cases, we need to: 1. Use the same wl_surface even after client_surface_release 2. Use the same wl_surface for each successive call to pCreateClientSurface. However, this would conflict with the OpenGL behavior according to dlls/win32u/opengl.c, so we would need to differentiate between an OpenGL and Vulkan client surface. Should I move this to win32u like the unused_drawable member of the WND structure? Note: Mesa 26.1 and lower have a WSI bug that causes this solution to not work in the case of VkSurface leaks, which I have fixed here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34918 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11342

4 22

[PATCH 0/1] MR11686: winex11: fix use-after-free in GL_EXTENSIONS string
by Hugo Barrera (＠whynothugo) Aug. 20, 2026

Aug. 20, 2026

X11DRV_WineGL_InitOpenglInfo() creates a temporary GLX context, records glGetString(GL_EXTENSIONS) into the static glExtensions, then destroys that context at 'done'. The string belongs to the context, so glExtensions is left dangling. It is read much later from x11drv_init_wgl_extensions(), which win32u calls as a driver entry point: has_extension opengl.c:337 x11drv_init_wgl_extensions opengl.c:1417 display_funcs_init (win32u) On glibc the freed memory usually stays mapped and the bug goes unnoticed. On musl the allocator releases the pages, so this faults: Exception 0xc0000005 at winex11.so ... has_extension This makes winex11.drv's DllMain return FALSE, so no display driver is ever registered and every GUI process falls back to the null driver: err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. Copy the string before the temporary context is destroyed, so the static outlives it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11686

3 4

[PATCH 0/1] MR11715: ntdll: Preserve exception flags when converting between x64 and arm64 context flags.
by Jacek Caban (＠jacek) Aug. 20, 2026

Aug. 20, 2026

Fixes test_context_exception_request tests on arm64ec. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11715

2 1

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

On Thu Aug 20 11:03:25 2026 +0000, Andrea Faulds wrote: > I rewrote it, hopefully the new variant works. The new variant works. The test failures in `systray.c` are unrelated (they happen for all MRs touching `shell32` right now): ``` shell32:systray start dlls/shell32/tests/systray.c systray.c:49:0.016 Test failed: NIM_ADD failed! systray.c:50:0.016 Test failed: GetLastError() = 2147500037 systray.c:75:0.016 Test failed: NIM_ADD failed! systray.c:76:0.016 Test failed: GetLastError() = 2147500037 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149368

1 0

[PATCH v4 0/2] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

This works on Windows, but was broken in WINE: ![Screenshot From 2026-08-20 01-13-02.png](/uploads/4cf087c2d5ab538700b881a72d07a366/Screenshot_From_2026-08-20_01-13-02.png){width=731 height=600} ![Screenshot From 2026-08-20 01-33-09.png](/uploads/787690a027523a914821143824dcc3ab/Screenshot_From_2026-08-20_01-33-09.png){width=731 height=600} The three patches belong together because `ShellExecute` invokes explorer. -- v4: shell32: Fix ShellExecute not accepting GUID shell folder paths explorer: Fix GUID shell folder paths not being accepted on command line https://gitlab.winehq.org/wine/wine/-/merge_requests/11709

2 2

[PATCH v3 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

This works on Windows, but was broken in WINE: ![Screenshot From 2026-08-20 01-13-02.png](/uploads/4cf087c2d5ab538700b881a72d07a366/Screenshot_From_2026-08-20_01-13-02.png){width=731 height=600} ![Screenshot From 2026-08-20 01-33-09.png](/uploads/787690a027523a914821143824dcc3ab/Screenshot_From_2026-08-20_01-33-09.png){width=731 height=600} The three patches belong together because `ShellExecute` invokes explorer. -- v3: shell32: Fix ShellExecute not accepting GUID shell folder paths explorer: Fix GUID shell folder paths not being accepted on command line shell32/tests: Add test for ShellExecute with GUID shell folder path https://gitlab.winehq.org/wine/wine/-/merge_requests/11709

2 4

[PATCH v2 0/7] MR11711: wbemdisp: Fixes and implementations part 1.
by Conor McCarthy (＠cmccarthy) Aug. 20, 2026

Aug. 20, 2026

-- v2: wbemdisp: Return null object on failure of QueryInterface(). wbemdisp: Implement ISWbemObject::GetTypeInfo(). wbemdisp: Partially implement get ISWbemObjectPath::DisplayName. wbemdisp: Add ISWbemObjectPath stub implementation. wbemdisp: Handle null output pointer in enumvar_Next(). https://gitlab.winehq.org/wine/wine/-/merge_requests/11711

3 9

[PATCH v2 0/2] MR11714: gdiplus/metafile: Allow drawimage w/o attributes
by Tobi Laskowski (＠tobil) Aug. 20, 2026

Aug. 20, 2026

As stated in the documentation, the attribute id is optional: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/77… Without the patch, emf+ files that contain records with an empty image attribute field do not render properly since those records are rejected. -- v2: gdiplus/metafile: Allow drawimage w/o attributes gdiplus/tests: Check drawimage w/o attributes https://gitlab.winehq.org/wine/wine/-/merge_requests/11714

2 2

[PATCH 0/2] MR11714: gdiplus/metafile: Allow drawimage w/o attributes
by Tobi Laskowski (＠tobil) Aug. 20, 2026

Aug. 20, 2026

As stated in the documentation, the attribute id is optional: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/77… Without the patch, emf+ files that contain records with an empty image attribute field do not render properly since those records are rejected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11714

2 2

[PATCH 0/1] MR11687: comctl32/toolbar: Preserve list toolbar button height.
by Maotong Zhang (＠xiaotong) Aug. 20, 2026

Aug. 20, 2026

Avoid updating the button height for TBSTYLE_LIST toolbars without a valid image list and with 1x1 bitmap dimensions. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60168 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11687

3 2