- Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/7] MR9979: mf/tests: Test SAR's IMFPresentationTimeSource interface.
by Brendan McGrath (＠redmcg) Feb. 5, 2026

Feb. 5, 2026

On Thu Jan 29 20:11:09 2026 +0000, Brendan McGrath wrote: > Sorry, I still haven't looked in to this. One thing I did recall seeing > is ([src](https://learn.microsoft.com/en-us/windows/win32/medfound/streaming-aud…) > > If the playback rate is faster or slower than 1×, the SAR > automatically adjusts the pitch. > This makes it sound like SAR itself does pitch scaling and therefore > probably also defines those values. But I'll need to investigate further > to be sure. I suspect this may be hard coded in SAR. I tried every media type (using `IMFMediaTypeHandler::SetCurrentMediaType`) on every device (using `MF_AUDIO_RENDERER_ATTRIBUTE_ENDPOINT_ID`) and it was always the same result: ``` slowest rate 0.125000 fastest rate 8.000000 ``` I tested the following devices: ``` Speakers (3- High Definition Audio Device) Headphones (3- High Definition Audio Device) SMBX2450 (NVIDIA High Definition Audio) Digital Audio (S/PDIF) (3- High Definition Audio Device) ``` And the following subtypes: ``` MFAudioFormat_Dolby_AC3_SPDIF MFAudioFormat_DTS MFAudioFormat_Float MFAudioFormat_Float_SpatialObjects ``` The only sample rate I tested though was 48kHz. None of the devices on my PC offered a media type with a different value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9979#note_128838

1 0

[PATCH 0/2] MR8368: libs/xml2: Import upstream release 2.13.8.
by Daniel Lehman (＠dlehman25) Feb. 5, 2026

Feb. 5, 2026

import with 2 small changes: - config.h -> win32config.h - comment out deprecation to avoid warnings while preserving `xmlThrDefTreeIndentString` (for 8c792c25) https://testbot.winehq.org/JobDetails.pl?Key=158748 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8368

5 6

[PATCH v3 0/1] MR9956: wined3d: Check invalid addresses when copying buffer objects.
by Zhiyi Zhang (＠zhiyi) Feb. 5, 2026

Feb. 5, 2026

When a thread that created windows is being closed, the destination buffer address might be NULL. For example: 1. context_gl->internal_format_set is set to 1 in wined3d_context_gl_set_pixel_format(). 2. A thread gets destroyed, all the windows in the thread get destroyed. 3. wined3d_context_gl_set_pixel_format() fails because WindowFromDC() returns NULL. 4. get_dc_pixel_format() fails in win32u_wglMakeContextCurrentARB(). 5. wined3d_buffer_gl_create_buffer_object() fails to create a buffer object. 6. wined3d_buffer_get_memory() returns a struct wined3d_bo_address with addr being NULL. Adding a NULL check in wined3d_context_gl_copy_bo_address() avoids triggering write segfaults when terminating a thread. This could happen for React Native applications. -- v3: wined3d: Reset internal format when using the backup DC. https://gitlab.winehq.org/wine/wine/-/merge_requests/9956

3 5

[PATCH 0/2] MR10014: ntdll, mountmgr.sys: Report free space for "important" data on macOS.
by Tim Clem (＠tclem) Feb. 4, 2026

Feb. 4, 2026

Brings the number in line with that reported by Finder. --- fstatvfs on macOS returns the immediately available space on-disk, but the Finder shows a different number, which accounts for "reclaimable" space (i.e., that used by purgeable caches and other temporary data). That reclaimable space is available for Wine to use, and the difference between the two figures can sometimes be dramatic. We should ideally show what Finder shows. It is unfortunate to have to resort to `fcntl(F_GETPATH)` here, but the CF functions require CFURLs for paths and do not operate on fds. There does not seem to be a way to get the reclaimable space figures taking quotas into account (i.e. the difference between bfree and bavail). However there is AFAIK no supported way to enable quotas on macOS, so it strikes me as exceedingly unlikely that that would matter. I'm effectively setting CallerAvailableAllocationUnits and ActualAvailableAllocationUnits to the same value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10014

3 3

[PATCH v6 0/7] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing ~~DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml)~~ This was already done !10004 Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v6: libs/xml2: Tolerate embedded XML declarations inside elements. mshtml/tests: Remove XMLSerializer from todo list and add prototype props check. mshtml/tests: Fix method_reference_call test to use .call() for proper this binding. mshtml/msxml3: Add tests for XMLSerializer and embedded XML declaration handling. mshtml: Return E_ACCESSDENIED for METHOD|PROPERTYGET on function objects in quirks mode mshtml/tests: Re-add test_method_vs_getter for DISPATCH_METHOD|DISPATCH_PROPERTYGET handling mshtml/msxml3: Add IXMLSerializer implementation and CDATA wrapping for embedded XML declarations https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

2 8

[PATCH v5 0/6] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling, and fix DISPATCH_METHOD|PROPERTYGET for ES5+
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml) - Fixes ES5+ handling that was breaking method calls with arguments - When `cArgs > 0`, treats the call as `DISPATCH_METHOD` (actual method invocation) - When `cArgs == 0`, uses ES5+ behavior preferring `DISPATCH_PROPERTYGET` (property access) - In quirks mode (pre-IE9), returns `E_ACCESSDENIED` for `METHOD|PROPERTYGET` on function objects to match Windows Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v5: mshtml/tests: Remove XMLSerializer from todo list and add prototype props check. mshtml/tests: Fix method_reference_call test to use .call() for proper this binding. mshtml/msxml3: Add tests for XMLSerializer and embedded XML declaration handling. mshtml: Return E_ACCESSDENIED for METHOD|PROPERTYGET on function objects in quirks mode mshtml/tests: Re-add test_method_vs_getter for DISPATCH_METHOD|DISPATCH_PROPERTYGET handling https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

2 6

[PATCH v4 0/7] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling, and fix DISPATCH_METHOD|PROPERTYGET for ES5+
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml) - Fixes ES5+ handling that was breaking method calls with arguments - When `cArgs > 0`, treats the call as `DISPATCH_METHOD` (actual method invocation) - When `cArgs == 0`, uses ES5+ behavior preferring `DISPATCH_PROPERTYGET` (property access) - In quirks mode (pre-IE9), returns `E_ACCESSDENIED` for `METHOD|PROPERTYGET` on function objects to match Windows Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v4: mshtml/tests: Remove XMLSerializer from todo list and add prototype props check. https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

4 11

[PATCH v2 0/1] MR9751: Draft: gitlab: Make core files accessible as artifacts.
by Bernhard Übelacker Feb. 4, 2026

Feb. 4, 2026

All some days there is an issue with the `debian-32` gitlab job showing a segfault. But it also shows `core dumped`. This merge request is the attempt to make this core file available as artifact. Last segfault example from yesterday: https://gitlab.winehq.org/wine/wine/-/jobs/216539#L135 ``` /usr/bin/bash: line 213: 185 Segmentation fault (core dumped) wine usr/local/lib/wine/i386-windows/winetest.exe -q ``` -- v2: gitlab: Make core files accessible as artifacts. https://gitlab.winehq.org/wine/wine/-/merge_requests/9751

3 17

Re: [PATCH v2 0/1] MR10032: winemac.drv: Only set the app icon once per process. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10032

1 0

Re: [PATCH v6 0/6] MR9977: wineandroid: Fix build issues and early runtime regressions on modern Android toolchains
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

I merged most of these, the remaining ones will need some more thought. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977#note_128816

1 0

Re: [PATCH v3 0/3] MR10031: msxml3/sax: Add some traces for setting handlers. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10031

1 0

Re: [PATCH v2 0/6] MR10030: Add symbols in d3d12.idl and d3d12sdklayers.idl for pcsx2 - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10030

1 0

Re: [PATCH v6 0/6] MR9977: wineandroid: Fix build issues and early runtime regressions on modern Android toolchains - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977

1 0

Re: [PATCH v2 0/1] MR10029: odbcad32: Add stub program. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10029

1 0

Re: [PATCH v2 0/3] MR10023: wined3d/spirv: Pass vkd3d_shader_d3dbc_source_info. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10023

1 0

Re: [PATCH v2 0/2] MR10024: wined3d: Reset internal_format_set when using the backup DC. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10024

1 0

Re: [PATCH v2 0/2] MR10028: server: Only try to grab atom for string window properties. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10028

1 0

Re: [PATCH v3 0/2] MR10004: jscript: Fix DISPATCH_METHOD | DISPATCH_PROPERTYGET in ES5+ modes. - approved
by Alexandre Julliard (＠julliard) Feb. 4, 2026

Feb. 4, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10004

1 0

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Nikolay Sivov (＠nsivov) Feb. 4, 2026

Feb. 4, 2026

On Wed Feb 4 20:30:48 2026 +0000, Juergen R. wrote: > @nsivov I also use the T@x from buhl and Wine version 11.0 (stable). The > problem displaying an empty preview (see related defect) still occurs. > After the last comment from Nikolay I expected that the patch of > `d2d_geometry_group_init` is merged. I also could not find the patch > above in the wine d2d1.dll. Could you please check for the listed patch > to merge? You are probably testing with Wine 11.0 and not Wine-staging 11.0? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_128790

1 0

[PATCH 0/1] MR10032: winemac.drv: Only set the app icon once per process.
by Tim Clem (＠tclem) Feb. 4, 2026

Feb. 4, 2026

set_app_icon does quite a bit of work, and macdrv_SetDesktopWindow may be called from multiple threads. We only need to do it once. --- We used to only do this in process_attach before e4a43cfa1f44b4458bd347ce473846daa18f9326, when it was rightly moved so that we can ensure GDI is all set up. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10032

3 2

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Juergen R. (＠GitJR) Feb. 4, 2026

Feb. 4, 2026

@nsivov I also use the T@x from buhl and Wine version 11.0 (stable). The problem displaying an empty preview (see related defect) still occurs. After the last comment from Nikolay I expected that the patch of `d2d_geometry_group_init` is merged. I also could not find the patch above in the wine d2d1.dll. Could you please check for the listed patch to merge? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_128786

1 0

[PATCH v2 0/3] MR10031: msxml3/sax: Add some traces for setting handlers.
by Nikolay Sivov (＠nsivov) Feb. 4, 2026

Feb. 4, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: msxml3/saxreader: Make sure VB startElement/endElement are never called with a NULL uri. https://gitlab.winehq.org/wine/wine/-/merge_requests/10031

2 4

[PATCH 0/3] MR10031: msxml3/sax: Add some traces for setting handlers.
by Nikolay Sivov (＠nsivov) Feb. 4, 2026

Feb. 4, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10031

2 3

[PATCH 0/6] MR10030: Add symbols in d3d12.idl and d3d12sdklayers.idl for pcsx2
by Biswapriyo Nath (＠Biswa96) Feb. 4, 2026

Feb. 4, 2026

Reported here https://github.com/mingw-w64/mingw-w64/issues/159 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10030

2 6

[PATCH 0/7] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon Feb. 4, 2026

Feb. 4, 2026

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

2 8