December 2025 - Wine-GitLab

[PATCH v3 0/1] MR2498: msado15: Implement _Recordset Find
by Alistair Leslie-Hughes (＠alesliehughes) Feb. 3, 2026

Feb. 3, 2026

Find only supports one Column to filter on. The parser for this will be the same for both Find/Filter with the only different is the Filter supports multiple columns. In trying to keep this patch small, only WSTR/BSTR/Integer have been supported. (The Common cases). -- v3: msado15: Implement _Recordset Find https://gitlab.winehq.org/wine/wine/-/merge_requests/2498

3 3

[PATCH v7 0/4] MR359: mmdevapi: copy ContainerID property from audio driver if available
by Claire (＠ClearlyClaire) Feb. 3, 2026

Feb. 3, 2026

Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR allows this information to be accessible from the IMMDevice's property store when the audio driver provides it (none for now, but I intend to add that feature to `winepulse.drv` and maybe `winealsa.drv`) This is made specific to containerId rather than supporting VT_CLSID on every property because Wine currently stores VT_BLOBs directly in the registry value, which does not allow us to safely disambiguate between VT_CLSID and VT_BLOB values when reading from registry. -- v7: mmdevapi: Invalidate ContainerID of unavailable audio devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/359

7 12

[PATCH 0/1] MR8406: wined3d: Make sure swapchain can't be used after being released.
by Yuxuan Shui (＠yshui) Feb. 2, 2026

Feb. 2, 2026

In wined3d_swapchain_cleanup, before decrementing the reference counts of each of the back/front buffers, we first set their swapchain to NULL, presumably to stop the current under-destruction swapchain from being used through them. But there is an oversight. When we call wined3d_texture_decref on the front_buffer, the back_buffers still have their swapchains pointing to the swapchain being destroyed. In texture_resource_unload, we call context_acquire(device, NULL, 0), note the NULL texture parameter here. When the texture parameter is NULL, wined3d_context_gl_acquire (in turn called by context_acquire) will default to using the first back buffer from the implicit swapchain of "device", which, as previously stated, has not had their swapchain set to NULL yet. From here, we reach wined3d_context_gl_activate with a texture whose swapchain is currently being destroyed. This swapchain is then assigned to "context_gl" here before being freed, leaving a dangling pointer. When this context_gl is acquired again later, we will try to access context_gl->c.swapchain->win_handle, thus complete the use-after-free cycle. This commit makes sure the swapchain pointer of ALL front and back buffers are set to NULL before decrementing their reference counts. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58325 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8406

4 7

[PATCH v8 0/6] MR7466: mf: Fix some issues with seeking.
by Conor McCarthy (＠cmccarthy) Feb. 2, 2026

Feb. 2, 2026

-- v8: mf: Initialise the grabber sample count when setting state after a seek. mf: Do not count draining a downstream node as a request fulfillment. mf: Do not count placing the stream sink ENDOFSEGMENT marker as a request fulfillment. mf/tests: Wait for session closure at the end of test_media_session_Start(). mf/tests: Test pause followed by immediate restart at current time in test_media_session_Start(). mf/tests: Test sample delivery where applicable in test_media_session_Start(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7466

3 8

[PATCH 0/1] MR8712: strmbase: Get rid of stream_cs.
by Conor McCarthy (＠cmccarthy) Feb. 2, 2026

Feb. 2, 2026

The following sequence can occur: sink_EndOfStream, lock stream_cs, renderer sink_eos, strmbase_passthrough_eos, IMediaSeeking_GetStopPosition, MediaSeekingPassThru_GetStopPosition, get_connected, IPin_ConnectedTo, lock filter_cs And at the same time: filter_Stop, lock filter_cs, dmo_wrapper_cleanup_stream, lock stream_cs Resulting in deadlock. This can occur in Space Engineers. dmo_wrapper_cleanup_stream() locks stream_cs to access `pin.peer` and `pin.pAllocator`, which are normally protected by filter_cs, but this lock was added to fix a test failure, so I don't know if there's an alternative. I'm concerned about the possible performance impact of removing stream_cs though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8712

4 3

[PATCH v13 0/1] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Jan. 31, 2026

Jan. 31, 2026

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- v13: cabinet: lzx compression support https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

4 3

[PATCH v4 0/2] MR9639: Fix the integration of PowerPoint add-in in MS Office 2016
by Ivan Lyugaev (＠valy) Jan. 28, 2026

Jan. 28, 2026

Encountered an issue with PowerPoint add-in integration. Reviewing the logs revealed the problem was due to the lack of CLSID lookup via the CurVer section and incorrect handling of the PARAMFLAG_NONE flag. A test was conducted in Windows to verify the handling of PARAMFLAG_NONE, PARAMFLAG_FIN, and PARAMFLAG_FOUT. Test class: ``` interface ITest : IDispatch { [id(1)] HRESULT TestMethod(BSTR* value); [id(2)] HRESULT TestMethodOut([out] BSTR* retVal); [id(3)] HRESULT TestMethodIn([in] BSTR* inVal); }; ``` Results in Windows: ``` --------TestMethod-------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethod] Hello from VT_BSTR Invoke returned: 0x00000000 -------TestMethodIn------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethodIn] Hello from VT_BSTR Invoke returned: 0x00000000 -------TestMethodOut------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethodOut] (null) Invoke returned: 0x00000000 ``` Results in Wine: ``` --------TestMethod-------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethod] (null) Invoke returned: 0x00000000 -------TestMethodIn------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethodIn] Hello from VT_BSTR Invoke returned: 0x00000000 -------TestMethodOut------- Variant type: 0x0008 (VT_BSTR) [CTest::TestMethodOut] (null) ``` Therefore, parameters with the PARAMFLAG_NONE flag are implied to be input parameters in Windows and are handled accordingly as PARAMFLAG_FIN. Added tests for the implemented changes. In the last two tests (their code is provided below), the CLSID is nullified in the guid_from_string function, which is why this test is left with a todo_wine tag. ``` clsid = CLSID_StdFont; hr = CLSIDFromString(L"MyApp.DocumentTest.3", &clsid); todo_wine ok(IsEqualCLSID(&clsid, &CLSID_StdFont), "Unexpected clsid %s.\n", wine_dbgstr_guid(&clsid)); clsid = CLSID_StdFont; hr = CLSIDFromString(L"MyApp.DocumentTest.5", &clsid); todo_wine ok(IsEqualCLSID(&clsid, &CLSID_StdFont), "Unexpected clsid %s.\n", wine_dbgstr_guid(&clsid)); ``` -- v4: combase: Implement CLSID lookup with CurVer fallback oleaut32: Fix parameter value loss in ITypeInfo_Invoke for byref parameters https://gitlab.winehq.org/wine/wine/-/merge_requests/9639

3 8

[PATCH v16 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) Jan. 27, 2026

Jan. 27, 2026

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? -- v16: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. kernel32: Use GetCurrentProcess() handle in CreateToolhelp32Snapshot if possible. kernel32/tests: Test CreateToolhelp32Snapshot with TH32CS_SNAPMODULE32. kernel32: Fix CreateToolhelp32Snapshot on old WoW64. include: Add TH32CS_SNAPMODULE32. kernel32/tests: Handle ERROR_BAD_LENGTH from CreateToolhelp32Snapshot. kernel32/tests: Fix CreateToolhelp32Snapshot failure check. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

4 10

[PATCH 0/1] MR8586: mshtml: Fix node's onclick not responding.
by Yongjie Yao (＠yaoyongjie) Jan. 26, 2026

Jan. 26, 2026

When installing the photoshop-setup.exe version of Photoshop 2025, there is no response after clicking the continue button. The reasons are as follows: As a property of the node, setting events such as onclick on the node does not respond when clicked. The following jscript code was executed during the installation of Photoshop 2025: $("#continueButton").attr("onclick", "continueBtnClicked('installOptionsContinueClicked'); return false;"); -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8586

5 12

[PATCH v4 0/3] MR7659: windows.devices.bluetooth: Add implementation for IBluetoothStatics::GetDefaultAsync(), BluetoothAdapter.
by Vibhav Pant (＠vibhavp) Jan. 26, 2026

Jan. 26, 2026

This MR adds a basic implementation for the BluetoothAdapter interface in Windows.Devices.Bluetooth, including winebth.sys support for getting properties associated with the radio's Low Energy capabilities. -- v4: windows.devices.bluetooth: Implement BluetoothAdapter::get_BluetoothAddress. windows.devices.bluetooth: Implement IBluetoothAdapterStatics::GetDefaultAsync(). windows.devices.bluetooth/tests: Add tests for IBluetoothAdapter. https://gitlab.winehq.org/wine/wine/-/merge_requests/7659

3 5

[PATCH 0/1] MR9486: windowscodecs: correct GIF LZW compression initialization
by Jiajin Cui (＠jin-king1) Jan. 22, 2026

Jan. 22, 2026

The GIF LZW compression algorithm was incorrectly initializing the code size to 8 bits regardless of the actual color depth. This caused issues with images that have fewer colors requiring smaller initial code sizes. The fix calculates the proper initial code size based on the actual number of colors in the image, using the formula: minimum code size = max(2, ceil(log2(color_count))). This ensures proper compression for images with small color palettes and maintains compatibility with GIF decoders that expect correct LZW initialization parameters. Log: Fixed GIF compression for images with small color palettes Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9486

6 9

[PATCH v13 0/3] MR7539: combase : clsid_from_string_reg() add read of CurVer key value.
by Maotong Zhang (＠xiaotong) Jan. 21, 2026

Jan. 21, 2026

If the read ProgID only has a CurVer key and no CLSID key, it will directly return CO_E_CCLASSSTRING, causing the program to fail to continue running. Add the key value for finding CurVer. -- v13: combase:clsid_from_string_reg() add read of CurVer key value. ole32:Do not zero out when not a CLSID ole32/tests:Remove now succeeding todo_wine https://gitlab.winehq.org/wine/wine/-/merge_requests/7539

4 6

[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 v3 0/5] MR9651: dmsynth: More robust sink write and render scheduling
by Anton Baskanov (＠baskanov) Jan. 19, 2026

Jan. 19, 2026

-- v3: dmsynth: Clear the buffer notifications before closing the event handle. dmsynth: Estimate a continuously-advancing buffer position for a more precise timing. dmsynth: Call GetCurrentPosition from a separate thread. dmsynth: Simplify synth_sink_wait_play_end by making it similar to the main rendering loop. dmsynth: Try to maintain a fixed write latency by varying the wait time. https://gitlab.winehq.org/wine/wine/-/merge_requests/9651

3 8

[PATCH 0/1] MR9629: configure: Add option for building with split debug info.
by Yuxuan Shui (＠yshui) Jan. 15, 2026

Jan. 15, 2026

* * * all the machinery for split debug info is there, and the only thing needed is just exposing a flag from `configure`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9629

4 5

[PATCH v3 0/1] MR9764: msi/tests: Fix some typos (Coverity).
by Sven Baars (＠sbaars) Jan. 15, 2026

Jan. 15, 2026

-- v3: msi/tests: Fix some typos (Coverity). https://gitlab.winehq.org/wine/wine/-/merge_requests/9764

3 2

[PATCH v2 0/1] MR9742: mf: Prevent invalid topologies from being started.
by Bernhard Kölbl Jan. 14, 2026

Jan. 14, 2026

Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com> -- v2: mf: Prevent invalid topologies from being started. https://gitlab.winehq.org/wine/wine/-/merge_requests/9742

2 3

[PATCH v3 0/3] MR7429: winex11: Support absolute rawinput events and use window-relative coordinates.
by Rémi Bernon Jan. 14, 2026

Jan. 14, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51357 Now that we're tracking window position changes as they arrive, they should always be consistent with the received mouse input events. Absolute rawinput is useful for tablets, touchpad or touchscreen when they are exposed as absolute mouse devices. -- v3: winex11: Use window-relative coordinates for mouse input. winex11: Add support for absolute position in RawMotion events. winex11: Clear the MOUSEEVENTF_MOVE flag when accumulating motion. https://gitlab.winehq.org/wine/wine/-/merge_requests/7429

3 6

[PATCH 0/1] MR8452: Draft: gitlab: Set WINEPREFIX to a job workspace sub-directory.
by Rémi Bernon Jan. 14, 2026

Jan. 14, 2026

Although I have trouble reproducing it I still experience weird test failures whenever I create or updated separate MRs in a short amount of time. These failures are usually coming from unexpected display settings, although each job is running within docker in an isolated environment. I don't have any explanation for this, and I have confirmed that separate X server are spawned. However, the prefix used for the tests is initialized to /home/gitlab/.wine and I suspect this could perhaps be mounted and shared across containers? It could also explain the failures, if, for instance wineserver starts while another instance (invisible as isolated in a separate container) is running and has updated the registry on disk with different display settings while the tests are being executed. This is hypothetical but nonetheless I think it's better to keep the prefix in a job workspace sub-directory. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8452

3 6

[PATCH v2 0/4] MR9510: Draft: win32u: Implement timeline semaphore rewinding.
by Rémi Bernon Jan. 14, 2026

Jan. 14, 2026

Pretty much the same kind of thing Proton does, this is only for non-shared semaphores for now. This creates timeline events backed by host timeline semaphores, for every wait and signal operation on a client timeline semaphore. Events are host timeline semaphores with monotonically increasing values. One event is a `(host semaphore, value)` unique tuple, and their value is incremented every time they get signaled. They can be reused right away as a different event, with the new value. Signaled events are queued to a per-device event list for reuse, as we cannot safely destroy them [^1] and as creating them might be costly. A thread is spawned for every device that uses timeline semaphores, monitoring the events and semaphore value changes. The semaphore wrapper keeps the current client semaphore value, which is read directly by `vkGetSemaphoreCounterValue`. CPU and GPU waits on the client semaphore are swapped with a wait on a timeline event, and GPU signals with a signal on a timeline event. CPU signals simply update the client semaphore value on the wrapper, signaling the timeline thread to check and notify any waiter. The timeline thread waits on signal events, coming from the GPU, and on a per-device semaphore for CPU notifications (wait/signal list updates, CPU-side signal). It will then signal any pending wait for a client semaphore value that has been reached, and removes timed out waits. --- For shared semaphores my idea is to use the client timeline semaphore host handle itself as a signal to notify other device threads of semaphore value changes, as the host semaphore is what is exported and imported in other devices. The timeline threads would wait on that semaphore too in addition to the signal events and thread notification semaphore. The main issue with shared semaphores actually comes from sharing the client semaphore values, so that they can be read from each device timeline threads as well as from other processes. There's two scenarios to support, one that is for in-process sharing which could perhaps keep the information locally, but we also need to support cross-process sharing so I think there's no other way than to involve wineserver. My idea then is to move shared semaphore client value to wineserver, which will cost a request on every signal and wait (and reading the value for waits could later be moved to a shared memory object). This will also allow us to implement `D3DKMTWaitForSynchronizationObjectFromCpu` which might be useful for D3D12 fence implementation as it'll allow us to translate a timeline semaphore wait to an asynchronous NT event signal. [^1]: Vulkan spec indicates that semaphores may only be destroyed *after* every operation that uses them has fully executed, and it's unclear whether signaling or waiting a semaphore is enough as an indicator for full execution or whether we would need to wait on a submit fence. -- v2: win32u: Implement timeline semaphore rewinding support. win32u: Make a copy of the timeline semaphore value arrays. win32u: Spawn a device thread for timeline semaphores. win32u: Hook more vulkan timeline semaphore functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9510

3 9

[PATCH 0/1] MR4709: winedbg: Show all loaded modules in automatic backtrace.
by Bernhard Übelacker Jan. 10, 2026

Jan. 10, 2026

This patch should change the module list in the automatic backtraces from "info share" to "info wow share". That way all loaded modules should get listed instead of just the process native ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4709

3 5

[PATCH v7 0/1] MR3410: advpack: Add nullcheck for parameter that can be null (Coverity)
by Fabian Maurer (＠DarkShadow44) Jan. 8, 2026

Jan. 8, 2026

-- v7: advpack: Add nullchecks for parameters that can be null (Coverity) https://gitlab.winehq.org/wine/wine/-/merge_requests/3410

4 8

[PATCH v7 0/3] MR9789: winebus: Use smallest report size for joystick axis
by SeongChan Lee (＠foriequal0) Jan. 6, 2026

Jan. 6, 2026

Some games don't handle 32-bit sized joystick axes well. Assetto Corsa Rally, which was released a month ago as an early access and is still v0.1, is a recent example. The proof of concept 16-bit patch resolves the problem for many users and hardware on Linux, (https://github.com/ValveSoftware/Proton/issues/9220#issuecomment-3647591465) and users with open-source hardware confirmed the behavior of the game on Windows. Since it's the case that the game is non-compliant while the wine is perfectly compliant, we might be able to push and wait for the developer to release the fix, but I believe that the fix will also help to improve compatibility for some old, non-maintained, non-compliant games. -- v7: winebus: Use smallest report size for unsigned axis too winebus: Use 16-bit relative axis range for bus_sdl winebus: Use smallest report size for joystick axis https://gitlab.winehq.org/wine/wine/-/merge_requests/9789

3 5

[PATCH 0/1] MR9841: winex11.drv: Don't send -1 fullscreen monitor indices to window managers.
by Zhiyi Zhang (＠zhiyi) Jan. 5, 2026

Jan. 5, 2026

Fix a regression from 3bea06b8. This partly reverts 6a2e414d, which introduced this bug initially. With 3bea06b8, it becomes much more likely that indices (-1, -1, -1, -1) got sent to window managers. This can happen, for example, a game with a 1920x1080 window changes the display resolution to 3840x2160, then changes the window size to 3840x2160. After the resolution change and before the window size change, xinerama_get_fullscreen_monitors() will return monitor indices (-1, -1, -1, -1) because 1920x1080 is not fullscreen. While sending a _NET_WM_FULLSCREEN_MONITORS client message with fullscreen monitor indices (-1, -1, -1, -1) clears the _NET_WM_FULLSCREEN_MONITORS property for a window on KWin, it can also make the window to disappear and lose focus. See KWin X11Window::fullscreenMonitorsArea()[1] and X11Window::updateFullscreenMonitors()[2]. Note that QRect is constructed with an empty rect at the beginning of X11Window::fullscreenMonitorsArea(). So fullscreen monitor indices (-1, -1, -1, -1) will produce an empty rect for moveResize() in X11Window::updateFullscreenMonitors() and cause the window to disappear. While indices (-1, 0, 0, 0) might work, I think it's better not to change _NET_WM_FULLSCREEN_MONITORS when the window is not fullscreen because removing the property is not part of any standard. [1]: https://invent.kde.org/plasma/kwin-x11/-/blob/v6.5.4/src/x11window.cpp?ref_… [2]: https://invent.kde.org/plasma/kwin-x11/-/blob/v6.5.4/src/x11window.cpp?ref_… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59180 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9841

3 2