- Wine-GitLab - list.winehq.org

[PATCH v7 0/2] MR9660: jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter in ES5+ modes.
by Gabriel Ivăncescu Jan. 20, 2026

Jan. 20, 2026

-- v7: mshtml: Handle DISPATCH_PROPERTYGET | DISPATCH_METHOD in dispex_value as jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter https://gitlab.winehq.org/wine/wine/-/merge_requests/9660

2 3

[PATCH v3 0/4] MR9915: mmedvapi: Device name changes.
by Bernhard Kölbl Jan. 20, 2026

Jan. 20, 2026

The test in the last commit would still need an implementation, which turned out to be more complicated than the possible benefits. -- v3: mmdevapi/tests: Test for DEVPKEY_Device_FriendlyName in the registry. mmdevapi: Adjust device names. mmdevapi/tests: Check device friendly name pattern. mmdevapi/tests: Simplify a trace. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

2 8

[PATCH v7 0/5] MR9572: opengl32: Implement GL_EXT_memory_object_win32 for base handle types.
by Derek Lesho (＠dlesho) Jan. 20, 2026

Jan. 20, 2026

Not sure about the extension replacement mechanism. Also, should tests be failing when extensions aren't supported? -- v7: opengl32: Expose GL_EXT_memory_object_win32. win32u/opengl: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. opengl32, win32u: Move gl_error to wgl_context. https://gitlab.winehq.org/wine/wine/-/merge_requests/9572

3 6

[PATCH v3 0/6] MR9616: Draft: opengl32: Implement GL_EXT_semaphore_win32 for base handle types.
by Derek Lesho (＠dlesho) Jan. 20, 2026

Jan. 20, 2026

Depends on !9574 and !9572 . -- v3: opengl32: Expose GL_EXT_memory_object_win32 and GL_EXT_semaphore_win32. win32u/opengl: Implement glImportSemaphoreWin32(Handle/Name)EXT for opaque handle types. win32u/opengl: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. opengl32, win32u: Move gl_error to wgl_context. win32u/opengl: Implement GL_DEVICE_LUID_EXT and GL_DEVICE_NODE_MASK_EXT. opengl32: Cleanup glGet* and fix typo in glGetDoublev. https://gitlab.winehq.org/wine/wine/-/merge_requests/9616

4 10

[PATCH 0/1] MR9937: winegstreamer: Protect wg_transform drain and flush by mutex.
by Charlotte Pabst (＠CharlottePabst) Jan. 20, 2026

Jan. 20, 2026

When flushing and draining at the same time from different threads without synchronization, one of them may fail and in the worst case, both fail, and the pipeline gets permanently stuck in EOS state. I'm dealing with a game that drains the Video Decoder MFT immediately after sending a stop command to the media session. In some cases, after the session is started again, the decoder does not output any samples anymore. The simple instance of this bug (with only one of them failing) stems from either drain-related events being pushed while the src pad is flushing, or flush-related events being pushed while the src pad is EOS. This does not cause any problems in the application. In the more complex case, the flush-stop event is processed by some pads (src in particular) but not yet the entire pipeline when a context switch happens, meaning that when the draining thread pushes its EOS event, it fails at a later pad (complete_drain then also fails), but is still stored as sticky in the src pad. After flush-stop finishes propagating, the stored EOS event then also propagates, leaving all pads in EOS state. This is the main problem I'm concerned about. I'm attaching `GST_DEBUG="4,WINE:9,GST_PADS:6,GST_EVENT:6"` logs for the EOS bug, as well as a test program. Note that the EOS case is comparatively rare. I'm unsure if this is the best fix for this issue, feel free to suggest something different. [flush-drain.c](/uploads/4e48cdea79a32867974c49b0aa2637c6/flush-drain.c) [flush-drain-bug.log](/uploads/9e873f0e807ecc665565a152bbade9d7/flush-drain-bug.log) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9937

3 2

[PATCH 0/1] MR9936: msado15: Fix WrapDSOandSession usage in connection_Open.
by Piotr Caban (＠piotr) Jan. 20, 2026

Jan. 20, 2026

Fixes regression introduced by 3bc4b5a9f. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9936

2 1

[PATCH v3 0/3] MR9926: ntdll: Make RtlEncodePointer / RtlDecodePointer compatible.
by Paul Gofman (＠gofman) Jan. 20, 2026

Jan. 20, 2026

-- v3: ntdll: Reimplement RtlEncodePointer / RtlDecodePointer using process cookie. https://gitlab.winehq.org/wine/wine/-/merge_requests/9926

2 4

[PATCH v2 0/4] MR9915: mmedvapi: Device name changes.
by Bernhard Kölbl Jan. 20, 2026

Jan. 20, 2026

The test in the last commit would still need an implementation, which turned out to be more complicated than the possible benefits. -- v2: mmdevapi/tests: Test for DEVPKEY_Device_FriendlyName in the registry. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

1 4

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Matteo Bruni (＠Mystral) Jan. 20, 2026

Jan. 20, 2026

> Here are my changes: !9928 I left a large comment over there which I'm not replicating here :sweat_smile: Good job though! > I also tried to add AVX+FMA3 versions of the resampling functions, but I'm getting diminishing returns. The bottleneck might be the indirect calls to `get` and `put` or the index calculation code in the outer loop. I haven't tried myself but I suspect this is where the computational complexity of the current filter comes back to bite us. As much as you can make the arithmetic and data accesses faster, it's always going to be ~60 multiplications and additions fetching data from 2 "large" arrays per sample for a FIR / sinc filter vs one order of magnitude fewer arithmetic operations, accessing a single large input data array for a cubic one. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_127395

1 0

[PATCH 0/28] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) Jan. 20, 2026

Jan. 20, 2026

This implements a number of optimizations, in particular: - Swapping around the resampling loops in case of downsampling, allowing the FIR step to stay fixed regardless of the resampling ratio. - Rearranging the FIR array elements to make the access sequential. - Adding SSE versions of the resampling functions. Together, these amount to more than a 5x reduction of `cp_fields_resample` execution time. The quality of the resampling should be the same, or even improve slightly, due to a more precise `rem` calculation and removal of the FIR step rounding, although I haven't yet conducted any measurements. -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/9928

2 1

[PATCH 0/1] MR9934: propsys: Fix parameter type of PropVariantToGUID.
by Biswapriyo Nath (＠Biswa96) Jan. 20, 2026

Jan. 20, 2026

Fixes: 4646ed19aec1 ("propsys: Added partial PropVariantToGUID implementation.") Fixes: 208de163affe ("propsys/tests: Added PropVariantToGUID tests.") Reported in https://github.com/mingw-w64/mingw-w64/issues/153 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9934

2 1

[PATCH 0/1] MR9933: fusion: Create the legacy GAC directory in CreateAssemblyCache().
by Hans Leidekker (＠hans) Jan. 20, 2026

Jan. 20, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45930 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9933

2 1

[PATCH 0/1] MR9932: ncrypt: Support ECDSA_P256.
by Hans Leidekker (＠hans) Jan. 20, 2026

Jan. 20, 2026

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

2 1

[PATCH 0/5] MR9931: winevulkan: Cleanups and simplifications for make_vulkan.
by Rémi Bernon Jan. 20, 2026

Jan. 20, 2026

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

1 5

[PATCH v2 0/2] MR9916: win32u: Fixup Vulkan deviceName to match win32u GPU name.
by Paul Gofman (＠gofman) Jan. 20, 2026

Jan. 20, 2026

-- v2: win32u: Fixup Vulkan deviceName to match win32u GPU name. https://gitlab.winehq.org/wine/wine/-/merge_requests/9916

3 4

[PATCH 0/2] MR9929: msado15: Respect DBPROP_CANHOLDROWS property in cache_get().
by Piotr Caban (＠piotr) Jan. 20, 2026

Jan. 20, 2026

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

2 2

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Anton Baskanov (＠baskanov) Jan. 20, 2026

Jan. 20, 2026

On Mon Jan 12 13:30:33 2026 +0000, Matteo Bruni wrote: > I'm curious about your changes. All things being equal it would be > preferable to improve the existing resampler rather than introducing a > different one. The problem is that I'm not sure we can make it fast > enough without effectively rewriting it from scratch. > When I wrote this MR I felt like the current resampler might be > hopelessly too complex for realtime resampling of 100+ sound buffers > (which is what Fallout 3 and New Vegas can end up with on occasion). I > benchmarked Wine's dsound resampling and compared the performance to > Windows. I also tested plugging resamplers from other common libraries > (speexdsp and libsamplerate, before openal-soft) into Wine's dsound, and > that kinda reinforced my view. The fastest fsinc implementation I tried > (which is from openal-soft) is still about half as fast as Win 10 / > 11's, IIRC. > I can go look at the actual numbers but I'm pretty sure a 5x improvement > when using explicit SSE does not quite cut it. > I'll mention that, since I wrote this MR, I have prepared a few more > patches to improve on other pieces of the dsound mixer, which become the > bottleneck once the resampler itself gets fast enough. You can find it > at https://gitlab.winehq.org/Mystral/wine/-/commits/dsound-perf (I > cleaned the patches up locally since I pushed all that to gitlab, but > the gist should be there already). For reference, these are the changes: > - Prepare all the input samples and store all the generated output > samples in one go instead of doing it sample-by-sample > - Don't use indirect function calls for sample conversion > - Don't use indirect function calls for channel interleaving > - Interleave channels after mixing > - Mix and apply volume at the same time > - SSE mixing > These patches give some incremental performance improvements. It's > possible that the combination of these and an improved version of the > current resampler gets us where we want, although I'm not super hopeful... Here are my changes: !9928 > When I wrote this MR I felt like the current resampler might be hopelessly too complex for realtime resampling of 100+ sound buffers (which is what Fallout 3 and New Vegas can end up with on occasion). That's interesting. My changes seem to be enough to fix the crackling in Star Wolves 3, which also creates 100+ buffers. Tested on a laptop with AMD Ryzen 5 3500U with the frequency reduced to 1400 GHz. I also tried to add AVX+FMA3 versions of the resampling functions, but I'm getting diminishing returns. The bottleneck might be the indirect calls to `get` and `put` or the index calculation code in the outer loop. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_127381

1 0

[PATCH v2 0/3] MR9926: ntdll: Make RtlEncodePointer / RtlDecodePointer compatible.
by Paul Gofman (＠gofman) Jan. 19, 2026

Jan. 19, 2026

-- v2: ntdll: Reimplement RtlEncodePointer / RtlDecodePointer using process cookie. https://gitlab.winehq.org/wine/wine/-/merge_requests/9926

2 5

[PATCH 0/3] MR9926: ntdll: Make RtlEncodePointer / RtlDecodePointer compatible.
by Paul Gofman (＠gofman) Jan. 19, 2026

Jan. 19, 2026

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

3 5

[PATCH 0/2] MR9927: mountmgr: Implement FileFsFullSizeInformationEx.
by Elizabeth Figura (＠zfigura) Jan. 19, 2026

Jan. 19, 2026

No application I am aware of needs this. We currently have an awkward divide between volume/disk/drive ioctls (and NtQueryVolumeInformationFile classes, which are technically not ioctls). Some are implemented in mountmgr, some in ntdll, some in both, and one (FSCTL_DISMOUNT_VOLUME) in the server. Which version is called depends on how the device is opened. NT paths of the form \??\A: or \DosDevices\A: go to ntdll, but other paths, such as \Device\HarddiskVolume0 or \??\Volume{...}, go to mountmgr. It is my intent to move everything to mountmgr (with the exception of NtQueryVolumeInformationFile, which can be called on any file in the volume, not just the volume device or volume root. Note that in many cases we do ultimately forward these calls to mountmgr via get_mountmgr_fs_info() anyway.) This means the following: - FileFsFullSizeInformationEx implemented in mountmgr - FileFsDeviceInformation implemented in ntoskrnl (this one is actually handled by the I/O manager) - FSCTL_DISMOUNT_VOLUME moved from server to mountmgr. mountmgr will have to call the server to close open files as part of this. - Everything inside of cdrom.c would be moved to mountmgr. This is a lot of thrashing, but will ultimately result in more natural code; in particular the ugly hacks for IOCTL_STORAGE_EJECT_MEDIA and the "cache" can effectively go away. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9927

2 2

Re: [PATCH v2 0/5] MR9922: winevulkan: Misc make_vulkan extensions refactoring. - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

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

1 0

Re: [PATCH v6 0/2] MR9882: kernelbase: Trim whitespaces from the quoted 'cmdline' - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

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

1 0

Re: [PATCH v3 0/2] MR9466: gitlab: Install some missing dependencies. - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

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

1 0

Re: [PATCH v2 0/1] MR9906: ntdll: Make VEH registration structure compatible. - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

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

1 0

Re: [PATCH v2 0/1] MR9919: advapi32: Use same default values for both GetEffectiveRightsFromAclA/W - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

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

1 0