December 2025 - Wine-GitLab

[PATCH v3 0/5] MR9690: win32u: Implement OpenGL shared resources import.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

Supersedes !9616 and !9572 -- v3: win32u: Implement glImportSemaphoreWin32(Handle/Name)EXT for opaque handle types. win32u: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. https://gitlab.winehq.org/wine/wine/-/merge_requests/9690

2 6

[PATCH 0/1] MR9695: win32u: Require VK_KHR_external_semaphore_fd for keyed mutexes.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

We need to use vkImportSemaphoreFdKHR to import the keyed mutex sync object, and it will be NULL if the extension hasn't been enabled. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9695

1 1

[PATCH v2 0/5] MR9690: win32u: Implement OpenGL shared resources import.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

Supersedes !9616 and !9572 -- v2: win32u: Implement glImportSemaphoreWin32(Handle/Name)EXT for opaque handle types. win32u: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. win32u: Expose device LUID / nodes mask to opengl32. https://gitlab.winehq.org/wine/wine/-/merge_requests/9690

3 7

[PATCH v2 0/7] MR9693: mfsrcsnk: Implement thinning.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/8505 -- v2: mfsrcsnk: Implement thinning. mfsrcsnk: Peek for stream token presence without removing it. mfsrcsnk: Factor out a media_source_request_stream_sample helper. mfsrcsnk: Process SetRate asynchronously. mfsrcsnk: Introduce a DEFINE_MF_ASYNC_PARAMS macro. winedmo: Fall back to dts for sample time if pts is not present. mfsrcsnk/tests: Add tests for thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/9693

2 8

[PATCH 0/5] MR9690: win32u: Implement OpenGL shared resources import.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

Supersedes !9616 and !9572 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9690

3 7

[PATCH 0/10] MR9687: winebus, hidclass, dinput: Add bus_num and port_path to device_desc and use them in instance_id.
by Ivo Ivanov (＠logos128) Dec. 5, 2025

Dec. 5, 2025

Use only real serial numbers, otherwise return error on IOCTL_HID_GET_STRING, similar to Windows. Generate consistent container_id (winebus) based on either serial number, uid (macos LocationID), bus_num/port_path (Linux bus_udev) or input/index. Generate consistent guidInstance (dinput) based on device_id/instance_id extracted from the device_path. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9687

3 17

[PATCH v9 0/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) Dec. 5, 2025

Dec. 5, 2025

Follow-up to !8184. This also adds a bunch of helpers for writing media source tests (without involving the mf session) in mfsrcsnk, these could be helpful for more tests of this kind in the future. I'm somewhat unsure as to why we haven't done tests for source behavior so far: while those are plugins, applications rely on a bunch of things in the builtin sources that microsoft provides. Since this affects both mfsrcsnk and winegstreamer sources, tests should be run both with `HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler` enabled and disabled. Due to this I figured it'd make sense to implement everything first and then remove the test todo_wine's and the statements rejecting the thin parameter in a single commit ("Allow thinning"). Perhaps this could be solved more nicely by setting the registry key in the tests themselves? I'm unsure if that is something we do in tests, generally. `MEStreamThinMode` events need to be emitted between the last sample using the outdated thinning parameter and the first sample using the updated thinning parameter. The winegstreamer implementation for this turned out a bit complex, if there is a simpler way to do this please let me know. Regarding winegstreamer, note that buffers need to be intercepted before the decoder because decoders often discard `GST_BUFFER_FLAG_DELTA_UNIT` flags (which is already annoying in itself - it causes all samples to be marked as `MFSampleExtension_CleanPoint`, this should potentially be worked around in the future). But even besides that, intercepting before the decoder is the "proper" implementation, since the point of thinning is increasing decoding speed by skipping delta frames, tho there are some games that rely on the semantics as well. -- v9: mfsrcsnk: Implement thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

3 7

[PATCH 0/6] MR9693: mfsrcsnk: Implement thinning.
by Rémi Bernon Dec. 5, 2025

Dec. 5, 2025

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/8505 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9693

3 9

[PATCH v15 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) Dec. 5, 2025

Dec. 5, 2025

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- v15: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. kernel32: Use GetCurrentProcess() handle in CreateToolhelp32Snapshot if possible. kernel32/tests: Test CreateToolhelp32Snapshot with TH32CS_SNAPMODULE32. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

3 11

[PATCH v10 0/4] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 5, 2025

Dec. 5, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v10: comment out test code lines https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 4