- Wine-GitLab - list.winehq.org

[PATCH 0/6] MR11718: secur32: Further separation between lsa/user mode data.
by Piotr Caban (＠piotr) Aug. 20, 2026

Aug. 20, 2026

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

2 6

[PATCH v4 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> -- v4: d3dx10/tests: Add some sprites rendering tests. include: Add some matrix functions prototypes to d3dx10math.h d3dx10/sprite: Collect sprites on DrawSpritesBuffered(). d3dx10/sprite: Partially implement state restore functionality. d3dx10/tests: Add some tests for the sprite state saving feature. d3dx10/sprite: Check for the Begin/End state in affected methods. https://gitlab.winehq.org/wine/wine/-/merge_requests/11674

3 7

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