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

[PATCH 0/2] MR11219: Improve theming (Ability to set .theme globally, env var for boolean ones)
by Fatih Bakal (＠Twig) Aug. 25, 2026

Aug. 25, 2026

Allows .theme files to be set globally with an override environment variable named `WINE_IGNORE_GLOBAL_THEME` . Also allows `GTK_THEME` to be used for apps that make use of dark/light theme setting on windows (Example: https://github.com/keepassxreboot/keepassxc/releases/tag/2.6.6) . I thought of using `GTK_THEME` as users tend to already have that set. I haven't seen any breakage caused by the dark/light theme switch, but in case there is or it's preferred not to be that way for any other reason (e.g. user's windows app becoming dark theme after this commit if they have it set) I can switch it to `WINETHEME` . Examples: Upstream: ![image](/uploads/917478db4983575ac4333016e3bb79cf/image.png){width=312 height=357} With commits from my repo combined with a .theme file made off winlator's dark theme values: ![image](/uploads/654e7dd9beaef184576611a5933ab6f0/image.png){width=311 height=360} Keepassxc: ![image](/uploads/7815a52d2173f2d71ae47f7601966540/image.png){width=900 height=565} ![image](/uploads/8bcfae7e2180b5c16cf48b4f52c60e98/image.png){width=900 height=583} Please see; https://list.winehq.org/hyperkitty/list/wine-devel@list.winehq.org/thread/7… https://bugs.winehq.org/show_bug.cgi?id=59739 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11219

5 23

[PATCH v7 0/1] MR11387: start: Avoid buffer overflows during path lookup.
by Likun Li (＠lilikun124) Aug. 24, 2026

Aug. 24, 2026

start.exe searches for its first argument using fixed-size path buffers. Several normalized paths, path components, executable names, and PATHEXT entries were copied without consistent bounds checks, allowing a long protocol URL to cause an access violation before ShellExecuteExW. Validate each destination buffer operation and leave arguments that cannot be represented by the path search buffers unchanged for ShellExecuteExW. The later fix update adds a cmd.exe conformance test. It registers a temporary protocol and verifies that cmd.exe /c start passes a URL longer than MAX_PATH to its handler unchanged. Related merge request: !11386 adds per-user protocol lookup and desktop export for handlers registered under HKCU\\Software\\Classes. End-to-end Notion Calendar testing was performed with this MR and !11386 applied together. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57229 Signed-off-by: Likun Li lilikun124(a)gmail.com -- v7: start: Avoid buffer overflows during path lookup. https://gitlab.winehq.org/wine/wine/-/merge_requests/11387

3 5

[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 v2 0/1] MR11205: Winebus usb compatible ids
by Thomas Portal (＠OursCodeur) Aug. 20, 2026

Aug. 20, 2026

### What winebus reports the USB class compatible IDs (`USB\Class_03&SubClass_xx&Prot_y`y and the two shorter forms) for USB devices, alongside the existing WINEBUS\\WINE_COMP_HID id. wineusb.sys already reports these IDs in this format for the devices it enumerates (dlls/wineusb.sys/wineusb.c, get_compatible_ids). winebus does not, so its synthesized USB-HID devices look different from a real Windows USB-HID device to any application that validates the USB parent. This makes winebus do the same. ### Why On Windows the USB parent carries these IDs and applications validate them through `CM_Get_Parent` or `SetupDi`. Wine omits them, so those applications fail. The Elgato Stream Deck app is one concrete case: it reports "no device found" for a connected Stream Deck Mini and recognises it once the IDs are present. winebus has no separate USB interface device to host the IDs. On a real stack the interface PDO from usbccgp is the HID device's parent; under winebus the IDs are reported on the HID device itself, which is the device an application reaches from the HID node. Only the hosting device differs from Windows; the IDs and their format match what wineusb already reports. ### How The interface class, subclass and protocol come from the udev usb_interface node (bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol). get_compatible_ids formats them the same way wineusb.sys does, for USB devices that carry interface information, and keeps the existing ids ahead of them so driver binding is unchanged. ### Testing No automated test: winebus has no unit harness for the udev backend (the dinput HID test drives its own mock bus and never reaches this path), and the IDs derive from live sysfs values. Verified by hand: with the change the USB parent's CompatibleIds gains `USB\Class_03&SubClass_00&Prot_00` and the two shorter forms (read live from sysfs) alongside the existing WINE_COMP_HID, and the Elgato Stream Deck app then detects a connected Stream Deck Mini that it otherwise rejects. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59891 Signed-off-by: Thomas Portal portal.thomas(a)protonmail.com -- v2: winebus.sys: Report USB class compatible IDs. https://gitlab.winehq.org/wine/wine/-/merge_requests/11205

3 4

[PATCH v4 0/3] MR5988: winegstreamer: Output compressed samples from the media source.
by Elizabeth Figura (＠zfigura) Aug. 20, 2026

Aug. 20, 2026

-- v4: winegstreamer: Output compressed samples from the media source. winegstreamer: Stop on unparsed H.264 in autoplug-continue. winegstreamer: Explicitly append an H.264 parser for H.264. https://gitlab.winehq.org/wine/wine/-/merge_requests/5988

4 5

[PATCH 0/1] MR6387: configure: Fix build on CYGWIN & MinGW.
by Carlo Bramini (＠carlo-bramini) Aug. 18, 2026

Aug. 18, 2026

The macro `_GNU_SOURCE` isn't defined by default on CYGWIN and MinGW, but it must be added otherwise it won't find the prototypes of several functions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6387

4 4

[PATCH v6 0/2] MR11076: msxml3: Invoke onreadystatechange after a successful synchronous load.
by Rose Hellsing (＠axtlos) Aug. 17, 2026

Aug. 17, 2026

Native MSXML fires the onreadystatechange handler synchronously from within IXMLDOMDocument::load()/loadXML() once parsing completes and readyState reaches 4. Hosts that set the handler before calling load() and expect it to have run by the time control returns to the caller rely on this ordering; Wine currently invokes the handler only as part of the asynchronous parse path, so synchronous loads silently skip it. This is MR 1 out of 4 for https://bugs.winehq.org/show_bug.cgi?id=33474 -- v6: msxml3/tests: Test synchronous invocation of onreadystatechange from loadXML(). https://gitlab.winehq.org/wine/wine/-/merge_requests/11076

3 3

[PATCH v3 0/1] MR6007: ntdll: Don't use CLOCK_REALTIME_COARSE
by Tatsuyuki Ishi (＠ishitatsuyuki) Aug. 17, 2026

Aug. 17, 2026

This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for NtQuerySystemTime() if it has sufficient resolution.") CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000. OTOH, there are several ways to get up to 0.5ms resolution on modern Windows (high resolution waitable timers, NtSetTimerResolution with 0.5ms). This code path therefore has a possibility of behaving worse than native. Since COARSE resolution is HZ dependent, this code path only runs if the kernel is configured with CONFIG_HZ=1000. Most distro ships does not ship with this. Therefore, this code path is rarely tested, and is more of a recipe for surprise. If any application rely on fast NtQuerySystemTime they are likely already broken for majority of Wine users. Given the above reason, don't use CLOCK_REALTIME_COARSE. Use gettimeofday which is internally hooked to CLOCK_REALTIME. -- v3: ntdll: Don't use CLOCK_REALTIME_COARSE https://gitlab.winehq.org/wine/wine/-/merge_requests/6007

8 15

[PATCH v3 0/1] MR10108: ntdll: Never use CLOCK_REALTIME_COARSE.
by William Horvath (＠whrvt) Aug. 17, 2026

Aug. 17, 2026

This is required for deterministic timekeeping, as the CLOCK_REALTIME_COARSE path depends on the scheduling tickrate (CONFIG_HZ) the kernel was built with. Increasing the kernel tickrate to 1000 or greater will then result in decreased accuracy for anything calling NtQuerySystemTime, which some anti-cheat/DRM schemes are unhappy about (see wine bug). Being in the vDSO, clock_gettime(CLOCK_REALTIME) should not meaningfully impact performance when compared to CLOCK_REALTIME_COARSE. Furthermore, the CLOCK_REALTIME_COARSE code path is completely untested in CI, because the current CI runners are configured with CONFIG_HZ < 1000. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59420 -- v3: ntdll: Never use CLOCK_REALTIME_COARSE. https://gitlab.winehq.org/wine/wine/-/merge_requests/10108

3 3

[PATCH 0/1] MR11325: winspool: Avoid overflow because the size is insufficient.
by Haoyang Chen (＠chenhaoyang) Aug. 17, 2026

Aug. 17, 2026

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

3 4