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

[PATCH 0/2] MR11265: ntdll: Do not reopen directory file when setting the same directory path.
by Paul Gofman (＠gofman) June 25, 2026

June 25, 2026

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

2 3

[PATCH v7 0/1] MR11256: winewayland.drv/win32u/winevulkan: Wayland + Vulkan support for Steam/CEF
by Aleksandr Kosachev (＠gohryt) June 25, 2026

June 25, 2026

This is a very large merge request, so I think it needs some background: For a long time (the last 2-3 years), I used frogging Wine built with ntsync, wayland, and vulkan in wow64 mode. At some point, I noticed that the vulkan and gstreamer patches often broke and were very difficult to fix. Another big problem was that, although Wine was built with wayland support, it was practically impossible to use wayland – many windows were black, white, or rendered in the wrong places. I tried switching to a clean build of Wine from master, and that was a positive experience, but it was still impossible to work in wayland mode. Besides the black windows, which were fixed by disabling GPU rendering in the Chrome embedded framework, the most annoying thing was that the tray icons stuck out like windows in the middle of the screen, literally interfering with games. It so happened that the first patch was for support for the standard KDE tray (which is essentially the standard GNOME tray). This turned out to be fairly simple, although during testing (and actual use), there were several deadlocks that had to be fixed. The next step was that after the last few updates, disabling the GPU stopped helping with black screens in CEF applications. At that point, I had to create the first version of сomposer, which correctly distributed content on the screen, but had issues and also didn't work with the GPU enabled. Starting with this version, several of my friends also used my version of Wine as unpaid testers. Finally, I recently found myself laid off, and for the past few weeks I've been actively working on GPU support and updating composer, as well as fixing bugs in popular games like Gothic 1 Remake, for which I had to add EDID generation, and Dota, which constantly wanted to open incorrectly placed on the screen and did not accepted raw keys input. Now it's ready. This set of patches has now been tested by me and several of my friends on computers running KDE and GNOME, and it works almost flawlessly. I am sorry with this big merge request instead of atomic feature-related merge requests, but i developed this for a very long time on different computers and long time it was .patch file for the arch package since all my tester friends are either arch or steamos users. As a responsible person and contributor, I must also note that the LLM APIs from Claude, OpenAI, and Gemini were actively used during development. I checked, and at the time of development, all three providers fully transfer rights to the LLM generated output to the developer (me) in their license agreements, so i think it can be used with the Wine's GPL 2 license. A local version of Gemma 4 was also used with my own agent. I guarantee that all code was verified by me as a developer and tested on multiple computers with different environments but there were important limitation of the testing that I must also disclose is that all of testing machines were based on AMD graphics. I am unable to test this on NVIDIA or Intel-based machines because I do not have it. -- v7: winewayland.drv/win32u/winevulkan: Wayland + Vulkan support for Steam/CEF and games without disabling the GPU https://gitlab.winehq.org/wine/wine/-/merge_requests/11256

2 1

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

June 25, 2026

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

3 6

[PATCH v5 0/10] MR9687: winebus, hidclass, dinput: Add bus_num and port_path to device_desc and use them in instance_id.
by Ivo Ivanov (＠logos128) June 25, 2026

June 25, 2026

Use only real serial numbers, otherwise return error on IOCTL_HID_GET_STRING, similar to Windows. Generate consistent container_id (winebus) based on either serial number, uid (macos LocationID), bus_num/port_path (Linux bus_udev) or input/index. Generate consistent guidInstance (dinput) based on device_id/instance_id extracted from the device_path. -- v5: dinput: Make instance guid Data4 last bytes similar to Windows. winebus.sys: Make container_id consistent through Wine launches. winebus.sys: When no serial number is available, use bus_num and port_path when generating instance_id. winebus.sys: Add bus_num and port_path to struct device_desc. winebus.sys: Generate serial numbers only if there is no other way to get the real ones (SDL). winebus.sys: Change device index only on devices of the same model that have the same SN. winebus.sys: Don't use predefined (zeroed) serial numbers for devices without SN. winebus.sys: Return an error on IOCTL_HID_GET_STRING when no serial number is available. winebus.sys: Use unique serial numbers for mouse and keyboard devices. hidclass.sys: Use FDO instance_id instead of serial number for multi-TLC child PDOs. https://gitlab.winehq.org/wine/wine/-/merge_requests/9687

3 15

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

June 25, 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. -- v27: 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 v6 0/1] MR11256: winewayland.drv/win32u/winevulkan: Wayland + Vulkan support for Steam/CEF
by Aleksandr Kosachev (＠gohryt) June 25, 2026

June 25, 2026

This is a very large merge request, so I think it needs some background: For a long time (the last 2-3 years), I used frogging Wine built with ntsync, wayland, and vulkan in wow64 mode. At some point, I noticed that the vulkan and gstreamer patches often broke and were very difficult to fix. Another big problem was that, although Wine was built with wayland support, it was practically impossible to use wayland – many windows were black, white, or rendered in the wrong places. I tried switching to a clean build of Wine from master, and that was a positive experience, but it was still impossible to work in wayland mode. Besides the black windows, which were fixed by disabling GPU rendering in the Chrome embedded framework, the most annoying thing was that the tray icons stuck out like windows in the middle of the screen, literally interfering with games. It so happened that the first patch was for support for the standard KDE tray (which is essentially the standard GNOME tray). This turned out to be fairly simple, although during testing (and actual use), there were several deadlocks that had to be fixed. The next step was that after the last few updates, disabling the GPU stopped helping with black screens in CEF applications. At that point, I had to create the first version of сomposer, which correctly distributed content on the screen, but had issues and also didn't work with the GPU enabled. Starting with this version, several of my friends also used my version of Wine as unpaid testers. Finally, I recently found myself laid off, and for the past few weeks I've been actively working on GPU support and updating composer, as well as fixing bugs in popular games like Gothic 1 Remake, for which I had to add EDID generation, and Dota, which constantly wanted to open incorrectly placed on the screen and did not accepted raw keys input. Now it's ready. This set of patches has now been tested by me and several of my friends on computers running KDE and GNOME, and it works almost flawlessly. I am sorry with this big merge request instead of atomic feature-related merge requests, but i developed this for a very long time on different computers and long time it was .patch file for the arch package since all my tester friends are either arch or steamos users. As a responsible person and contributor, I must also note that the LLM APIs from Claude, OpenAI, and Gemini were actively used during development. I checked, and at the time of development, all three providers fully transfer rights to the LLM generated output to the developer (me) in their license agreements, so i think it can be used with the Wine's GPL 2 license. A local version of Gemma 4 was also used with my own agent. I guarantee that all code was verified by me as a developer and tested on multiple computers with different environments but there were important limitation of the testing that I must also disclose is that all of testing machines were based on AMD graphics. I am unable to test this on NVIDIA or Intel-based machines because I do not have it. -- v6: winewayland.drv/win32u/winevulkan: Wayland + Vulkan support for Steam/CEF and games without disabling the GPU https://gitlab.winehq.org/wine/wine/-/merge_requests/11256

2 1

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

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

2 2

[PATCH v4 0/5] MR11173: server: Update window zorder directly in queue_mouse_message.
by Rémi Bernon (＠rbernon) June 25, 2026

June 25, 2026

Instead of using an extra request on every mouse motion event. -- v4: server: Update window zorder directly in queue_mouse_message. server: Map update_window_zorder rect from raw to virtual coordinates. wineandroid: Let wineserver dispatch input when received on capture window. winemac: Let wineserver dispatch input when received on capture window. winex11: Let wineserver dispatch input when received on capture window. https://gitlab.winehq.org/wine/wine/-/merge_requests/11173

3 11

[PATCH 0/1] MR11261: wbemprox: Remove unused variable.
by Jacek Caban (＠jacek) June 25, 2026

June 25, 2026

Fixes -Wunused-but-set-global warnings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11261

3 2

[PATCH 0/4] MR11262: x11,vulkan,joy,winebus: Remove unused variables.
by Jacek Caban (＠jacek) June 25, 2026

June 25, 2026

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

3 5