- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR11621: Prefer hidraw for Valve devices
by Elizabeth Figura (＠zfigura) Aug. 20, 2026

Aug. 20, 2026

> It's difficult to decide whether we want that or not. It's indeed possible that it would allow Steam for Windows to recognize Valve hardware in a better way, but it's also possible that it would break other legitimate use cases like running Wine under Steam for Linux with Valve hardware handled by Steam on the Linux side directly. For upstream Wine wouldn't it make more sense to prioritize win32 Steam? Especially since Linux Steam is presumably always going to have its own modifications for various reasons. I know it's undesirable to have to carry another patch in Proton, but this one at least seems simple, directed, and fundamentally relevant to its being Proton. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11621#note_149410

1 0

[PATCH v3 0/6] MR11674: d3dx10: Some fixes and tests for sprites.
by Nikolay Sivov (＠nsivov) Aug. 20, 2026

Aug. 20, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v3: d3dx10/tests: Add some sprites rendering tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/11674

3 19

Re: [PATCH v2 0/1] MR11621: Prefer hidraw for Valve devices
by Rick Rey (＠AnAndroNerd) Aug. 20, 2026

Aug. 20, 2026

On Thu Aug 20 06:56:30 2026 +0000, Rémi Bernon wrote: > It's difficult to decide whether we want that or not. It's indeed > possible that it would allow Steam for Windows to recognize Valve > hardware in a better way, but it's also possible that it would break > other legitimate use cases like running Wine under Steam for Linux with > Valve hardware handled by Steam on the Linux side directly. > It doesn't seem possible to support both use cases by default, and the > latter is a Linux-only use case, but we also have many registry keys to > allow enabling hidraw for a specific VID if it's not the default. It > would be nice if that were good enough :). Is there anything I can do to get this approved? Currently if macOS users own a Steam Controller, they can’t use it at all under WINE without a 3rd party software. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11621#note_149398

1 0

[PATCH 0/1] MR11700: windows.storage.applicationdata: Implement IApplicationData local/roaming/temporary folders.
by Jaco van Zyl (＠pyr0hax) Aug. 20, 2026

Aug. 20, 2026

Implement IApplicationData::get_LocalFolder(), get_RoamingFolder() and get_TemporaryFolder() by returning a minimal IStorageFolder backed by a real directory, instead of the current E_NOTIMPL stub. Needed for SteelSeries GG, whose GGEZ.exe uses Microsoft.Data.Sqlite, which probes Windows.Storage.ApplicationData at startup to detect whether it's running in a packaged (UWP) context. Under Wine the ApplicationData object is obtained successfully, but querying any of these folder properties throws a NotImplementedException that isn't caught by the caller, crashing the whole process before it gets a chance to run. Signed-off-by: Jaco van Zyl <jvanzyl5(a)outlook.com> (pyr0hax) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11700

2 3

[PATCH v4 0/1] MR11716: shell32/tests: Mark systray test as flaky on Windows
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

It seems to fail on the Windows 10 runners for every MR that touches shell32 and thus triggers the test, but as far as I can tell there is nothing wrong with the test itself, and it does run fine in my Win10 VM. Related: https://bugs.winehq.org//show_bug.cgi?id=55017 -- v4: shell32/tests: Mark systray test as flaky on Windows https://gitlab.winehq.org/wine/wine/-/merge_requests/11716

2 3

[PATCH v3 0/1] MR11716: shell32/tests: Mark systray test as flaky on Windows
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

It seems to fail on the Windows 10 runners for every MR that touches shell32 and thus triggers the test, but as far as I can tell there is nothing wrong with the test itself, and it does run fine in my Win10 VM. -- v3: shell32/tests: Mark systray test as flaky on Windows https://gitlab.winehq.org/wine/wine/-/merge_requests/11716

2 2

[PATCH v2 0/1] MR11716: shell32/tests: Mark systray test as flaky on Windows
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

It seems to fail on the Windows 10 runners for every MR that touches shell32 and thus triggers the test, but as far as I can tell there is nothing wrong with the test itself, and it does run fine in my Win10 VM. -- v2: shell32/tests: Mark systray test as flaky on Windows https://gitlab.winehq.org/wine/wine/-/merge_requests/11716

2 1

[PATCH 0/1] MR11716: shell32/tests: Mark systray test as flaky on Windows
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

It seems to fail on the Windows 10 runners for every MR that touches shell32 and thus triggers the test, but as far as I can tell there is nothing wrong with the test itself, and it does run fine in my Win10 VM. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11716

2 1

[PATCH v6 0/3] MR11699: win32u and explorer: Exclude taskbar and appbars from system work area rect
by Andrea Faulds (＠hikari_no_yume) Aug. 20, 2026

Aug. 20, 2026

This is a package of changes that fix https://bugs.winehq.org/show_bug.cgi?id=59976 and possibly other issues. It is both a usability and a compatibility improvement. Please see the commit messages for further details. Feedback on if anything here is reasonable to write conformance tests for would be appreciated. I don't know if it makes sense for the IPC things. I did a bunch of manual testing of how Windows and WINE behave using two small test programs: [appbar.c](/uploads/49ed846bdbd32bfecdb0603304f5c332/testapp.c) and [workarea.c](/-/project/5/uploads/ab8f82c70d8df1e337e8b15be5f32cab/workarea.c). --- Before these changes: ![Screenshot From 2026-08-18 21-20-09.png](/uploads/75181aa0e0816399d1705a61ea8a21a0/Screenshot_From_2026-08-18_21-20-09.png){width="729" height="600"} ![Screenshot From 2026-08-18 21-20-14.png](/uploads/988c8becadd9ba1f928b9a50e4eda290/Screenshot_From_2026-08-18_21-20-14.png){width="729" height="600"} Note how: * The Office 97 Shortcut Bar is covering up part of the taskbar. This is worse if it's docked to the right (which is the default), because then it covers up system tray icons. * The maximized Word 97 window is covering up both the taskbar and the Shortcut Bar. After these changes: ![Screenshot From 2026-08-18 21-21-52.png](/uploads/56376b4356fd3a6b67c9596bd2271b25/Screenshot_From_2026-08-18_21-21-52.png){width="729" height="600"} You'll notice that the Word window here is still overhanging both the taskbar and the Shortcut Bar. I believe that's correct behavior as maximized windows always overhang the screen, and it just looks weird because WINE doesn't support `WS_EX_TOPMOST` yet in desktop mode. -- v6: explorer: Update system work area rect to exclude taskbar and appbars explorer: Account for the actual size of the taskbar if it is visible win32u: Apply work area changes to virtual desktop monitor serverwide https://gitlab.winehq.org/wine/wine/-/merge_requests/11699

3 11

[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