- Wine-gitlab - list.winehq.org

[PATCH v2 0/5] MR9583: dmusic: SF2 fixes, part 2
by Anton Baskanov (＠baskanov) 25 Nov '25

25 Nov '25

-- v2: dmusic: Take sample correction into account. dmusic: Add an 8 dB attenuation to normalize SF2 instrument volume. dmusic: Add IIR filter resonance hump compensation. dmusic: Set attenuation based on SF_GEN_INITIAL_ATTENUATION. https://gitlab.winehq.org/wine/wine/-/merge_requests/9583

4 10

[PATCH v6 0/2] MR9519: dlls/twain_32: Offer TWAIN DSM as twaindsm.dll for 64 Bit and send DAT_ENTRYPOINT earlier.
by Bernd Herd (＠herdsoft) 25 Nov '25

25 Nov '25

64-Bit Windows applications typically expect the Twain Data Source manager to be named twaindsm.dll. Send the DG_CONTROL/DAT_ENTRYPOINT/MSG_SET before DG_CONTROL/DAT_IDENTITY/MSG_OPENDS so sane.ds does not need to know the module name to find the DSM entry point. An explanation for the request to offer the name twaindsm.dll for 64-Bit windows is offered here by the TWAIN organization: https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc They cannot update the twain_32.dll installed and maintained by Microsoft, so they choose the new name twaindsm.dll instead. This name is also used at least by Irfanview and oder versions oder LibreOffice (Newer Libreoffice version start a 32-Bit process for 32-Bit TWAIN usage). This Merge request also changes the twain_32.dll so that it send it's entry points earlier, before opening the data source. This is the same behaviour as the twaindsm.dll from the TWAIN organization from [https://github.com/twain/twain-dsm/](https://github.com/twain/twain-dsm/blo… Otherwise sane.ds would in MSG_OPENDS try to find the DSM entry point based on the module-name "twain_32" in sane_main.c:60: ``` if (SANE_dsmentry == NULL) { HMODULE moddsm = GetModuleHandleW(L"twain_32"); if (moddsm) SANE_dsmentry = (void*)GetProcAddress(moddsm, "DSM_Entry"); if (!SANE_dsmentry) { ERR("can't find DSM entry point\n"); return TWRC_FAILURE; } } ``` -- v6: dlls/twaindsm: Implement DG_CONTROL/DAT_ENTRYPOINT/MSG_GET dlls/twaindsm, dlls/twain_32: Put DSM code into twaindsm.dll and add twain_32.dll wrapper https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

2 2

[PATCH v5 0/2] MR9519: dlls/twain_32: Offer TWAIN DSM as twaindsm.dll for 64 Bit and send DAT_ENTRYPOINT earlier.
by Bernd Herd (＠herdsoft) 25 Nov '25

25 Nov '25

64-Bit Windows applications typically expect the Twain Data Source manager to be named twaindsm.dll. Send the DG_CONTROL/DAT_ENTRYPOINT/MSG_SET before DG_CONTROL/DAT_IDENTITY/MSG_OPENDS so sane.ds does not need to know the module name to find the DSM entry point. An explanation for the request to offer the name twaindsm.dll for 64-Bit windows is offered here by the TWAIN organization: https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc They cannot update the twain_32.dll installed and maintained by Microsoft, so they choose the new name twaindsm.dll instead. This name is also used at least by Irfanview and oder versions oder LibreOffice (Newer Libreoffice version start a 32-Bit process for 32-Bit TWAIN usage). This Merge request also changes the twain_32.dll so that it send it's entry points earlier, before opening the data source. This is the same behaviour as the twaindsm.dll from the TWAIN organization from [https://github.com/twain/twain-dsm/](https://github.com/twain/twain-dsm/blo… Otherwise sane.ds would in MSG_OPENDS try to find the DSM entry point based on the module-name "twain_32" in sane_main.c:60: ``` if (SANE_dsmentry == NULL) { HMODULE moddsm = GetModuleHandleW(L"twain_32"); if (moddsm) SANE_dsmentry = (void*)GetProcAddress(moddsm, "DSM_Entry"); if (!SANE_dsmentry) { ERR("can't find DSM entry point\n"); return TWRC_FAILURE; } } ``` -- v5: dlls/twaindsm: Implement DG_CONTROL/DAT_ENTRYPOINT/MSG_GET dlls/twaindsm, dlls/twain_32: Put DSM code into twaindsm.dll and add twain_32.dll wrapper https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

2 2

[PATCH 0/2] MR9590: winex11: Pass client rect to create_client_window.
by Rémi Bernon 25 Nov '25

25 Nov '25

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/9584, that other MR isn't right with child client surface positioning. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9590

1 2

[PATCH v3 0/1] MR9288: chakra: Add stub dll.
by Mohamad Al-Jaf (＠maljaf) 25 Nov '25

25 Nov '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52741 -- v3: chakra: Add stub dll. https://gitlab.winehq.org/wine/wine/-/merge_requests/9288

3 3

[PATCH 0/1] MR9582: windowscodecs: Optimize a bit reading the 3bps RGB TIFF tile.
by Dmitry Timoshkov (＠dmitry) 25 Nov '25

25 Nov '25

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

3 2

[PATCH v2 0/4] MR9584: Draft: win32u: Update client surfaces starting from toplevel window.
by Rémi Bernon 25 Nov '25

25 Nov '25

In apply_window_pos, to notify any parent or children and let them make the necessary changes for offscreen rendering. -- v2: win32u: Update client surfaces starting from toplevel window. winex11: Update window position in client surface update callback. winex11: Remove some unnecessary NtUserGetClientRect calls. winex11: Pass client rect to create_client_window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9584

1 4

[PATCH v2 0/1] MR9573: win32u: Initialize surface with white colour on creation.
by Paul Gofman (＠gofman) 25 Nov '25

25 Nov '25

-- v2: win32u: Initialize surface with white colour on creation. https://gitlab.winehq.org/wine/wine/-/merge_requests/9573

3 3

[PATCH 0/2] MR9573: win32u: Initialize surface with white colour on creation.
by Paul Gofman (＠gofman) 25 Nov '25

25 Nov '25

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

3 7

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Matteo Bruni (＠Mystral) 25 Nov '25

25 Nov '25

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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_123681

1 0