December 2025 - Wine-GitLab

[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

[PATCH 0/2] MR9710: winegstreamer: Read input in chunks of 256KiB instead of 512KiB.
by Charlotte Pabst (＠CharlottePabst) Jan. 5, 2026

Jan. 5, 2026

Supersedes !8183. JR East Train Simulator's IMFByteStream implementation relies on the following two properties: - Reads are always aligned on a 256KiB boundary. - Reads are never larger than 256KiB. When chunking was initially benchmarked[1], a chunk size of 512KiB only performed marginally better than 256KiB, so this change has a negligible performance impact while being more correct. I'm testing using a WAV handler here because it's easy to create the data for it in memory (avoids including a large video file in git), but the same behavior can be observed with other handlers, such as MP4. [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/2390#note_27314 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9710

4 4

[PATCH 0/1] MR9838: opengl32: Avoid leaking memory on error paths (Coverity).
by Sven Baars (＠sbaars) Jan. 5, 2026

Jan. 5, 2026

Fixes 11728e0a9c58f1b7a8d320b05f1ce40e4fa3c790. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9838

3 2

[PATCH v4 0/2] MR9822: Fix possible EA launcher hangs.
by Zhiyi Zhang (＠zhiyi) Jan. 2, 2026

Jan. 2, 2026

Registering window classes in DllMain() is prone to deadlocks. Tests show that comctl32 window classes should probably be registered in RegisterClassNameW(). Fix possible EA launcher hangs due to deadlocks. A deadlock can happen, like the following, based on Tim Clem's findings. Say there are two threads, T1 and T2. T1: does some COM stuff that results in registering the window class OleMainThreadWndClass.\ T1: NtUserRegisterClassExWOW() does get_desktop_window(). Because this is not a built-in class.\ T1: doesn't yet have a desktop window, so it makes one and calls register_builtin_classes().\ T1: starts the pthread_once in register_builtin_classes() to actually register the classes.\ T1: starts calling NtUserRegisterClassExWOW() with its classes.\ T2: loads comctl32.dll, calls its PROCESS_ATTACH. It grabs the loader lock.\ T2: comctl32's DllMain starts registering its classes.\ T2: comctl32's attempts to register classes also call get_desktop_window().\ T2: get_desktop_window hits the pthread_once in register_builtin_classes() and starts waiting for T1 to finish it.\ T1: some built-in class registration results in a LoadImageW call for a class's cursor.\ T1: LoadImage has to grab a resource, so it tries to grab the loader lock.\ T1: the loader lock is held by T2. Deadlock; T2 is waiting on T1, which is waiting on T2. -- v4: comctl32: Register window classes in RegisterClassNameW() instead of DllMain(). comctl32/tests: Add more RegisterClassNameW() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9822

3 5