January 2026 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR9855: ntdll: get_non_pe_file_info() returns NTSTATUS.
by Dmitry Timoshkov (＠dmitry) Jan. 6, 2026

Jan. 6, 2026

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

3 2

Re: [PATCH v3 0/1] MR9796: winebus: Adjust hatswitch encoding to follow T300RS and G29
by Rémi Bernon Jan. 6, 2026

Jan. 6, 2026

I'm a bit surprised that we don't need adjustments on the dinput side, could you tweak one of the tests in dlls/dinput/tests/joystick8.c similarly to make sure everything is handling this pattern correctly? (Though I don't know if we have much tests with hatswitch, maybe worth adding a couple if not) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9796#note_126439

1 0

[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 v6 0/2] MR9840: winepulse.drv: A potential solution to audio crackling
by Dzmitry Keremsha (＠Vyrolian) Jan. 6, 2026

Jan. 6, 2026

I have noticed that winepulse leaves too little headroom when draining the buffer, which very often leads to crackling that can't be fully resolved by manipulating latency. Let's check some math: Let's assume that the buffer (tlength) is at 33ms, and minreq is at 13.3ms. If 13.2 ms were drained, the refill would be denied. If the next timer trigger takes 14ms due to jitter, that leaves us with a 6.1ms margin. As such, if we get any jitter longer than that during refill, we get an underflow. I think this is what leads to crackles. My solution increases timer polling to 5x the frequency, so if 13.2ms were drained, the next timer trigger would happen at around 16ms. That would leave us with a 17ms headroom. The math might not be 100% representation of what happens, but I think it's quite close to reality. On practice, this does indeed help to fully get rid of crackling for an indefinite amount of time, when before they were unevitable. I understand that this might be not the most elegant approach, the 5x increase is arbitrary. I had to add another if condition to NtSetEvent to avoid issues with spatialaudio. We need as much headroom as possible and tests were failing above 1.8, so I set it to 1.75 to be sure. I think this problem is quite urgent, because while this does not happen on every system, it's frequent enough that we see "Audio: Crackling" reports on most games on protondb and there are many forum threads about audio crackling. From my experience, the only solution was switching to winealsa, which is very consistent and does not crackle at all. My experience has been very consistent with forum threads when it came to the nature of crackling. I first noticed it in Balatro, which is a very light game and should not be crackling at all on any setup. Some games have very frequent crackling every 20-30 seconds, or a buzzsaw crackling every 10-15 minutes. I hope my idea brings us closer to the ultimate fix, I really look forward to your feedback! -- v6: Changed back to adv_bytes and spatial fix https://gitlab.winehq.org/wine/wine/-/merge_requests/9840

2 2

[PATCH v5 0/2] MR9840: winepulse.drv: A potential solution to audio crackling
by Dzmitry Keremsha (＠Vyrolian) Jan. 6, 2026

Jan. 6, 2026

I have noticed that winepulse leaves too little headroom when draining the buffer, which very often leads to crackling that can't be fully resolved by manipulating latency. Let's check some math: Let's assume that the buffer (tlength) is at 33ms, and minreq is at 13.3ms. If 13.2 ms were drained, the refill would be denied. If the next timer trigger takes 14ms due to jitter, that leaves us with a 6.1ms margin. As such, if we get any jitter longer than that during refill, we get an underflow. I think this is what leads to crackles. My solution increases timer polling to 5x the frequency, so if 13.2ms were drained, the next timer trigger would happen at around 16ms. That would leave us with a 17ms headroom. The math might not be 100% representation of what happens, but I think it's quite close to reality. On practice, this does indeed help to fully get rid of crackling for an indefinite amount of time, when before they were unevitable. I understand that this might be not the most elegant approach, the 5x increase is arbitrary. I had to add another if condition to NtSetEvent to avoid issues with spatialaudio. We need as much headroom as possible and tests were failing above 1.8, so I set it to 1.75 to be sure. I think this problem is quite urgent, because while this does not happen on every system, it's frequent enough that we see "Audio: Crackling" reports on most games on protondb and there are many forum threads about audio crackling. From my experience, the only solution was switching to winealsa, which is very consistent and does not crackle at all. My experience has been very consistent with forum threads when it came to the nature of crackling. I first noticed it in Balatro, which is a very light game and should not be crackling at all on any setup. Some games have very frequent crackling every 20-30 seconds, or a buzzsaw crackling every 10-15 minutes. I hope my idea brings us closer to the ultimate fix, I really look forward to your feedback! -- v5: Changed back to adv_bytes and spatial fix winepulse patch https://gitlab.winehq.org/wine/wine/-/merge_requests/9840

2 2

[PATCH v4 0/2] MR9840: winepulse.drv: A potential solution to audio crackling
by Dzmitry Keremsha (＠Vyrolian) Jan. 6, 2026

Jan. 6, 2026

I have noticed that winepulse leaves too little headroom when draining the buffer, which very often leads to crackling that can't be fully resolved by manipulating latency. Let's check some math: Let's assume that the buffer (tlength) is at 33ms, and minreq is at 13.3ms. If 13.2 ms were drained, the refill would be denied. If the next timer trigger takes 14ms due to jitter, that leaves us with a 6.1ms margin. As such, if we get any jitter longer than that during refill, we get an underflow. I think this is what leads to crackles. My solution increases timer polling to 5x the frequency, so if 13.2ms were drained, the next timer trigger would happen at around 16ms. That would leave us with a 17ms headroom. The math might not be 100% representation of what happens, but I think it's quite close to reality. On practice, this does indeed help to fully get rid of crackling for an indefinite amount of time, when before they were unevitable. I understand that this might be not the most elegant approach, the 5x increase is arbitrary. I had to add another if condition to NtSetEvent to avoid issues with spatialaudio. We need as much headroom as possible and tests were failing above 1.8, so I set it to 1.75 to be sure. I think this problem is quite urgent, because while this does not happen on every system, it's frequent enough that we see "Audio: Crackling" reports on most games on protondb and there are many forum threads about audio crackling. From my experience, the only solution was switching to winealsa, which is very consistent and does not crackle at all. My experience has been very consistent with forum threads when it came to the nature of crackling. I first noticed it in Balatro, which is a very light game and should not be crackling at all on any setup. Some games have very frequent crackling every 20-30 seconds, or a buzzsaw crackling every 10-15 minutes. I hope my idea brings us closer to the ultimate fix, I really look forward to your feedback! -- v4: Changed back to adv_bytes and spatial fix https://gitlab.winehq.org/wine/wine/-/merge_requests/9840

2 2

[PATCH v3 0/2] MR9840: winepulse.drv: A potential solution to audio crackling
by Dzmitry Keremsha (＠Vyrolian) Jan. 6, 2026

Jan. 6, 2026

I have noticed that winepulse leaves too little headroom when draining the buffer, which very often leads to crackling that can't be fully resolved by manipulating latency. Let's check some math: Let's assume that the buffer (tlength) is at 33ms, and minreq is at 13.3ms. If 13.2 ms were drained, the refill would be denied. If the next timer trigger takes 14ms due to jitter, that leaves us with a 6.1ms margin. As such, if we get any jitter longer than that during refill, we get an underflow. I think this is what leads to crackles. My solution increases timer polling to 5x the frequency, so if 13.2ms were drained, the next timer trigger would happen at around 16ms. That would leave us with a 17ms headroom. The math might not be 100% representation of what happens, but I think it's quite close to reality. On practice, this does indeed help to fully get rid of crackling for an indefinite amount of time, when before they were unevitable. I understand that this might be not the most elegant approach, the 5x increase is arbitrary. I had to add another if condition to NtSetEvent to avoid issues with spatialaudio. We need as much headroom as possible and tests were failing above 1.8, so I set it to 1.75 to be sure. I think this problem is quite urgent, because while this does not happen on every system, it's frequent enough that we see "Audio: Crackling" reports on most games on protondb and there are many forum threads about audio crackling. From my experience, the only solution was switching to winealsa, which is very consistent and does not crackle at all. My experience has been very consistent with forum threads when it came to the nature of crackling. I first noticed it in Balatro, which is a very light game and should not be crackling at all on any setup. Some games have very frequent crackling every 20-30 seconds, or a buzzsaw crackling every 10-15 minutes. I hope my idea brings us closer to the ultimate fix, I really look forward to your feedback! -- v3: Changed back to adv_bytes and spatial fix https://gitlab.winehq.org/wine/wine/-/merge_requests/9840

2 2

[PATCH v8 0/5] MR9843: wtsapi32: Fix session id and desktop handling when using CreateProcessAsUserW with tokens from WTSQueryUserToken
by Katharina Bogad (＠hackathi) Jan. 5, 2026

Jan. 5, 2026

This Merge request resolves [Wine-Bug #58588](https://bugs.winehq.org/show_bug.cgi?id=58588). The underlying problem was that services started on their own, non-interactive winstation, but within the current user's session. This is trivially not the case for system services on Windows: they run, by design, in other user contexts (e.g. NTAUTHORITY\SYSTEM). Whenever a service wants to start a process within another user's graphical session, it needs to set the session id to the correct value. This may be done using the WTS API. This MR implements this functionality in a (hopefully) wine-compatible way: 1. Patch wineserver so tokens can be transferred to other sessions 2. Implement NtSetInformationToken for TokenSessionId 3. Change the session of non-interactive services to session 0 (from the default session 1) in addition to setting their desktop to `__wineservice_winstation\Default` 4. Let CreateProcessAsUserW reset the desktop to the default value `__winsta0\Default` if the session of the to-be-created process is not a service session. This avoids implementing all user and session handling in-depth while still allowing the underlying functionality to work. A real-world user of this mechanism is the Dassault 3DEXPERIENCE launcher, which runs as a system service and wants to open interactive child processes within a user's scope. -- v8: kernelbase: Let CreateProcessInternalW overwrite the desktop if needed services: start services with session id 0 server: attach winstations to sessions, filter enum_windowstation wtsapi32: Make WTSQueryUserToken return a token with correct session id server: Allow changing of session id for process tokens https://gitlab.winehq.org/wine/wine/-/merge_requests/9843

2 6

Re: [PATCH v2 0/1] MR9841: winex11.drv: Don't send -1 fullscreen monitor indices to window managers. - approved
by Alexandre Julliard (＠julliard) Jan. 5, 2026

Jan. 5, 2026

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

1 0

Re: [PATCH v2 0/1] MR9838: opengl32: Avoid leaking memory on error paths (Coverity). - approved
by Alexandre Julliard (＠julliard) Jan. 5, 2026

Jan. 5, 2026

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

1 0