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

[PATCH 0/1] MR9866: Revert "ntdll: Switch to CLOCK_BOOTTIME for monotonic counters when available."
by Rémi Bernon Jan. 12, 2026

Jan. 12, 2026

This reverts commit 3d373e452388b60bea9dca6d5c4cf3f8b20a0c54. CLOCK_MONOTONIC_RAW is used in vulkan to correlate QPC timestamps, and there's no equivalent of CLOCK_BOOTTIME there. Using CLOCK_BOOTTIME for QPC breaks the vulkan side with no proper way to fix it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9866

2 3

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

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Anton Baskanov wrote: > Thanks for the detailed explanation. > > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. > I studied the code of the openal-soft sinc resampler, and I think that > our resampler is theoretically better: > - Our upsampling window width is 65.89 samples, which is much wider than > openal-soft's 24. This should result in a sharper pass-band to stop-band > transition, which means less aliasing. > - openal-soft's downsampling window is limited to 48 samples, whereas we > don’t have such a limit. > - The way openal-soft expands the upsampling window by linearly > interpolating between windows of different sizes is a bit questionable. > We expand the window by varying `dsbfirstep`, which should provide a > smoother transition. > > The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. > It shouldn't be too hard to change the window function in `make_fir`. > > Additionally, the position computation (`total_fir_steps`, `rem`) > using floats wasn't exact, which in turn caused some mid-high frequency distortion. > This can be easily fixed by using integer arithmetic: > <details> > <summary>Click to expand</summary> > ```diff > diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c > index b50d9f3a8c8..fe1c8a70db3 100644 > --- a/dlls/dsound/mixer.c > +++ b/dlls/dsound/mixer.c > @@ -365,12 +365,12 @@ static UINT > cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * > } > > for(i = 0; i < count; ++i) { > - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * > dsbfirstep / dsb->freqAdjustDen; > - float total_fir_steps = (freqAcc_start + i * > dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; > + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) > * dsbfirstep; > + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; > UINT ipos = int_fir_steps / dsbfirstep; > > UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; > - float rem = int_fir_steps + 1.0 - total_fir_steps; > + float rem = 1.0 - (fir_steps_num - int_fir_steps * > dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; > > int fir_used = 0; > while (idx < fir_len - 1) { > ``` > </details> > I also did some experiments, and I was able to make our resampler 5 > times faster without sacrificing the quality by rearranging the FIR > array and using SSE. Maybe we should give it a try. I'll try to come up > with a draft MR. 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... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126630

1 0

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

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Matteo Bruni wrote: > I should have mentioned it together with a few more things, but I forgot > :sweat_smile: > This is basically a C port of the default resampler from openal-soft. > It's MUCH faster while not being much worse in theoretical quality > compared to the old FIR resampler. In practice the old resampler had a > couple of shortcomings that lowered the effective quality[*], so I don't > think this is much a downgrade quality-wise. > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. It > is sensibly slower than this one though, and slower than Windows 10 / 11 > dsound's resampler. I'm not opposed to having it as an option; I did in > fact try to make the surrounding code somewhat generic to facilitate that. > The SSE2 version gives about a 2x speedup for me. For the records it > makes even more of a difference in openal-soft, most likely because we > start running into performance limitations in our dsound outside of the > resampler proper; I should have a few more patches to improve on that. > The SSE2 version is effectively always enabled on (x86) 64-bit. To > compile the SSE2 version on 32-bit you need to have `-msse2` in > `i386_CFLAGS`, or some other option that includes it (e.g. the typical > `-march=nocona` will do that). > [*]: The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. That > can introduce some aliasing or some distortion depending on the input > signal. Additionally, the position computation (`total_fir_steps`, > `rem`) using floats wasn't exact, which in turn caused some mid-high > frequency distortion. In fact I had originally preserved it when porting > the cubic resampler and I did see the same kind of distortion in the new > output, so I ended up using fixed point for that, which is also what > openal-soft does. Thanks for the detailed explanation. > Otherwise we could bring in the sinc resampler, which is theoretically very solid and still quite a bit faster than the old FIR resampler. I studied the code of the openal-soft sinc resampler, and I think that our resampler is theoretically better: - Our upsampling window width is 65.89 samples, which is much wider than openal-soft's 24. This should result in a sharper pass-band to stop-band transition, which means less aliasing. - openal-soft's downsampling window is limited to 48 samples, whereas we don’t have such a limit. - The way openal-soft expands the upsampling window by linearly interpolating between windows of different sizes is a bit questionable. We expand the window by varying `dsbfirstep`, which should provide a smoother transition. > The FIR resampler used a fixed Gaussian window instead of the parametrized Kaiser that's customarily used for audio resampling. It shouldn't be too hard to change the window function in `make_fir`. > Additionally, the position computation (`total_fir_steps`, `rem`) using floats wasn't exact, which in turn caused some mid-high frequency distortion. This can be easily fixed by using integer arithmetic: <details> <summary>Click to expand</summary> ```diff diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c index b50d9f3a8c8..fe1c8a70db3 100644 --- a/dlls/dsound/mixer.c +++ b/dlls/dsound/mixer.c @@ -365,12 +365,12 @@ static UINT cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * } for(i = 0; i < count; ++i) { - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / dsb->freqAdjustDen; - float total_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep; + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; UINT ipos = int_fir_steps / dsbfirstep; UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; - float rem = int_fir_steps + 1.0 - total_fir_steps; + float rem = 1.0 - (fir_steps_num - int_fir_steps * dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; int fir_used = 0; while (idx < fir_len - 1) { ``` </details> I also did some experiments, and I was able to make our resampler 5 times faster without sacrificing the quality by rearranging the FIR array and using SSE. Maybe we should give it a try. I'll try to come up with a draft MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126626

1 0

[PATCH v5 0/5] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 11, 2026

Jan. 11, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v5: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 6

[PATCH v4 0/5] MR9646: Draft: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 11, 2026

Jan. 11, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v4: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. mf/tests: Fix leaks in test source. mf/tests: Add ClockStateSink to test media sink. mf/tests: Modify test_seek_clock_sink to be ref counted. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 7

[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 4

[PATCH v10 0/11] MR9628: Implement pointer input APIs for multi-touch support
by Hecheng Yu (＠kde-yyds) Jan. 10, 2026

Jan. 10, 2026

These patches implemeted core pointer input APIs required by modern applications with touchscreen support, particularly Chromium and Qt-based applications. Implemented APIs: - GetPointerType: Query pointer input type (touch, pen, mouse) - GetPointerTouchInfo: Retrieve detailed touch pointer information - GetPointerFrameTouchInfo: Get all active touch pointers in current frame Added stubs: - SkipPointerFrameMessages: Used by applications to skip pointer frame processing like Qt - GetPointerFrameTouchInfoHistory: Historical touch frame data (not yet implemented) - GetPointerPenInfoHistory: Historical pen data (not yet implemented) System metrics changes: - SM_DIGITIZER: Reports touch capabilities (NID_INTEGRATED_TOUCH | NID_MULTI_INPUT | NID_READY) - SM_MAXIMUMTOUCHES: Returns maximum simultaneous touch points (10) Limitations: - We explictly set pointer type to PT_TOUCH when storing pointer info to queue, so GetPointerType will always return PT_TOUCH - GetPointerFrameTouchInfo returns 0 pointers after finger lift, while Windows returns 1 pointer with UP flags. And SkipPointerFrameMessages is currently a stub returning TRUE. Qt's pointer message processing uses both of them, but it's just working well Application requirements: - Chromium: Requires GetPointerType and GetPointerTouchInfo for touch input - Qt applications: Need GetPointerFrameTouchInfo and proper system metrics for multi-touch support - Qt5: Additionally checks for presence of all pointer APIs at runtime, requiring stubs to enable pointer messages processing -- v10: user32: Implement GetPointerFrameTouchInfo win32u: Implement NtUserGetPointerFrameTouchInfo user32: Implement GetPointerTouchInfo win32u: Implement NtUserGetPointerTouchInfo user32: Implement GetPointerType win32u: Implement NtUserGetPointerType win32u: Add pointer information cache and storage user32: Stub GetPointerPenInfoHistory user32: Stub GetPointerFrameTouchInfoHistory user32: Stub SkipPointerFrameMessages win32u: Add SM_DIGITIZER and SM_MAXIMUMTOUCHES system metrics https://gitlab.winehq.org/wine/wine/-/merge_requests/9628

3 13

[PATCH 0/1] MR9861: ntdll/unix/file.c: added new xattr for marking directories as readonly
by Rayan Halder (＠rayanh) Jan. 10, 2026

Jan. 10, 2026

On Windows, directories marked as readonly do not behave as readonly directories on linux. Readonly has no effect on windows but on querying for attributes, windows shows the directory to be readonly. To simulate this behaviour, an xattribute is being used to mark a directory as readonly. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50772 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9861

3 7

[PATCH v4 0/1] MR9858: qasf: Fix use-after-free of filter in reader callback.
by Yuxuan Shui (＠yshui) Jan. 9, 2026

Jan. 9, 2026

If a asf reader callback is invoked after its corresponding reader has been destroyed, it will still try to use the reader via asf_callback->filter, resulting in use-after-free. This commits sets asf_callback->filter to NULL when the reader is destroyed, and adds NULL checks to reader callback functions to make them no-op after the reader is destroyed. Fixes: Bug 59159 -- v4: qasf: Stop the WMReader first in asf_reader_destroy. https://gitlab.winehq.org/wine/wine/-/merge_requests/9858

3 8

[PATCH 0/1] MR9870: iccvid/tests: Reserve enough memory for input in test_formats (ASan).
by Bernhard Übelacker Jan. 9, 2026

Jan. 9, 2026

ASan got triggered by the new iccvid test. In `ICCVID_DecompressGetFormat` the input pointer gets read 484 (40+111*4) bytes, but variable `in` gets just the size of `BITMAPINFOHEADER`, 40 bytes allocated. CC: @zfigura [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161448) <details> <summary>ASan details [link](https://gitlab.winehq.org/bernhardu/wine/-/jobs/220743#L5427-L5452)</summary> ``` ==iccvid_test.exe==1720==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0022f8e8 at pc 0x784543e2 bp 0x0022f1f0 sp 0x0022edc0 READ of size 484 at 0x0022f8e8 thread T0 #0 0x784543e1 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x77fd22aa in ICCVID_DecompressGetFormat /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:836:9 #2 0x77fd1351 in ICCVID_DriverProc /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:1015:16 #3 0x78e92cf3 in DRIVER_SendMessage /builds/bernhardu/wine/build64/../dlls/winmm/driver.c:130:11 #4 0x78e92ba8 in SendDriverMessage /builds/bernhardu/wine/build64/../dlls/winmm/driver.c:150:11 #5 0x7902d7e0 in MSVIDEO_SendMessage /builds/bernhardu/wine/build64/../dlls/msvfw32/msvideo_main.c:198:15 #6 0x7902db20 in ICSendMessage /builds/bernhardu/wine/build64/../dlls/msvfw32/msvideo_main.c:1163:12 #7 0x0040190d in test_formats /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:62:11 #8 0x004010d9 in func_iccvid /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:196:5 #9 0x00404f51 in run_test /builds/bernhardu/wine/build64/../include/wine/test.h:780:5 #10 0x00404a6b in main /builds/bernhardu/wine/build64/../include/wine/test.h #11 0x00405f05 in mainCRTStartup /builds/bernhardu/wine/build64/../dlls/msvcrt/crt_main.c:62:11 #12 0x7bcd367f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b82367f) #13 0x7be4680a in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc4680a) #14 0x7be4717a in call_thread_func /builds/bernhardu/wine/build64/../dlls/ntdll/signal_i386.c:503:9 Address 0x0022f8e8 is located in stack of thread T0 at offset 1256 in frame #0 0x0040149f in test_formats /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:25 This frame has 3 object(s): [16, 1080) 'buffer' (line 26) [1216, 1256) 'in' (line 27) [1296, 1864) 'info' (line 30) <== Memory access at offset 1256 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:836:9 in ICCVID_DecompressGetFormat ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9870

1 1