August 2025 - Wine-gitlab - list.winehq.org

[PATCH 0/4] MR8827: opengl32: Redirect default framebuffer when using FBO surfaces.
by Rémi Bernon 25 Aug '25

25 Aug '25

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

1 4

[PATCH 0/1] MR8826: winscard: Handle NULL send parameter in SCardTransmit().
by Hans Leidekker (＠hans) 25 Aug '25

25 Aug '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58608 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8826

2 1

[PATCH v6 0/4] MR8808: winealsa, winecoreaudio, wineoss: Fixed MIDI reset Control Change
by Keigo Okamoto (＠KeigoOkamoto) 25 Aug '25

25 Aug '25

This pull request fixes Wine's MIDI synthesizer reset process to be the same as Windows'. When playing Touhou Project games in MIDI BGM mode, the music playback becomes buggy when the BGM changes. The video below is an example of an anomaly that occurs when playing The Fantastic Tales from Tono after playing Crystallized Silver in Touhou 7. https://youtu.be/O69sndJ45Ag Here's a correct example of The Fantastic Tales from Tono playback: https://youtu.be/XlFAQEbbNDg Piano sound is clearly missing on Wine. This issue occurs due to an Wine's incorrect reset process for MIDI synthesizer. When I ran FluidSynth on Windows and checked the log, I found that CC123 and CC121 were executed for each MIDI channel when switching songs. CC123 means All Notes Off, CC121 means Reset All Controllers. -- v6: Corrected the comment. wineoss: Send All Notes Off and Reset Controllers. winecoreaudio: Send All Notes Off and Reset Controllers. winealsa: Send All Notes Off and Reset Controllers. https://gitlab.winehq.org/wine/wine/-/merge_requests/8808

3 6

Re: [PATCH v10 0/1] MR8786: winebuild: Add flag to disable dynamicbase/aslr
by Tres Finocchiaro (＠tresf) 25 Aug '25

25 Aug '25

On Sat Aug 23 20:14:10 2025 +0000, Alexandre Julliard wrote: > Sure, that's fine. Ok, great, done. Let me know if there are any other changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113729

1 0

[PATCH v4 0/1] MR8134: d3d10/tests: Compile more test effects from sources.
by Nikolay Sivov (＠nsivov) 23 Aug '25

23 Aug '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v4: d3d10/tests: Compile more test effects from sources. https://gitlab.winehq.org/wine/wine/-/merge_requests/8134

2 1

[PATCH v9 0/1] MR8786: winebuild: Add flag to disable dynamicbase/aslr
by Tres Finocchiaro (＠tresf) 23 Aug '25

23 Aug '25

Commit 518e394794160818ffe6826c874ff2f550c95bbb introduced new and important default behavior for PE binaries built using `winegcc`/`wineg++`/`winebuild`. * `/DYNAMICBASE` - Generates an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows that was first available in Windows Vista. * `/HIGHENTROPYVA` - Randomized 64-bit virtual addresses make it more difficult for an attacker to guess the location of a particular memory region. ... however as identified in https://bugs.winehq.org/show_bug.cgi?id=58480, this new default behavior can severely impact applications that interact with binaries created for Windows XP and older. This is quite common for legacy audio plugins, such as VST2(TM) plugins. This MR keeps the new default "dynamicbase" and "highentropyva" flags by default, but mirrors the mingw/msys2 `--disable-dynamicbase` flag as explained here: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default. MSVC also provides a similarly named flag [here](https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase). Downstream, the LMMS project has successfully deployed the mingw flag and the MSVC flag for our Windows builds. Our Linux builds use a custom wine-bridge and would benefit from the same. We've currently tested this MR downstream against a snapshot of master branch to passing results. Downstream PRs: * Linux: https://github.com/LMMS/lmms/pull/7987 * Windows: https://github.com/LMMS/lmms/pull/7976 -- v9: winebuild: Add flag to disable dynamicbase/aslr https://gitlab.winehq.org/wine/wine/-/merge_requests/8786

3 3

[PATCH 0/3] MR8697: combase: Don't marshal objects marked as IAgileObject in RoGetAgileReference.
by Vibhav Pant (＠vibhavp) 23 Aug '25

23 Aug '25

[Chromium obtains an agile reference](https://source.chromium.org/chromium/chromium/src/+/main:device/… to WinRT activation factories with RoAgileReference. As we currently do not support marshaling WinRT objects, this fails. However, as objects marked with IAgileObject don't need to be marshaled across apartments, we can trivially implement `RoAgileReference` for such objects, as most activation factories tend to be agile. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8697

3 9

[PATCH v2 0/3] MR8823: d2d1: Add some helpers for geometry figure manipulation.
by Nikolay Sivov (＠nsivov) 23 Aug '25

23 Aug '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: d2d1: Implement rounded rectangle geometry simplification. d2d1: Implement ellipse geometry simplification. d2d1: Add some helpers for geometry figure manipulation. https://gitlab.winehq.org/wine/wine/-/merge_requests/8823

2 3

[PATCH 0/2] MR8824: winebus: Unspecified condition blocks are full strength
by Tyson Whitehead (＠twhitehead) 23 Aug '25

23 Aug '25

Under Windows and the PID specification it is possible to specify less than the full set of condition blocks. Under SDL and the Linux FF input API all condition blocks must always be specified. The existing code does not set any values outside the specified axes. This effectively sets the strength to zero along these axes. Testing setting just one axis with the MS Sidewinder 2 under Windows, however, reveals that revealed that it sets the first axis (the X-axis) to the given parameter values and sets the other axis to full strength (this is most easily felt/tested with the spring effect). This sets unspecified axes in the SDL and udev input backends to play at full strength to agree with Windows. It also updates joy.cpl to play condition effects along the indicated axis too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8824

2 3

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Stian Low (＠stianlow) 23 Aug '25

23 Aug '25

Summary of: https://bugs.winehq.org/show_bug.cgi?id=58552#c42 Windows versions of various audio apps handle VSTs better than Linux versions. This seems further prove that this merge request is valid despite bug reports against it. The more I review the more it seems this merge fixed bugs that made buggy code run in a less obviously buggy way. Thus it seems this merge may have helped expose fixes needed by Wine dependent VST projects. Yabridge fixes seem mostly fulfilled per new-wine10-embedding branch testing for vanilla-wine. But yabridge new-wine10-embedding still is not merged with upstream yet because of other reported issues caused by this merge. I will suggest to all reporters to test Windows versions of audio apps if available to confirm VST handling is improved. If most apps report improvements then it may suggest a common Windows lib is taking care of the lower level window handling details that so far have been difficult to replicate on Linux. With Windows versions proven to improve VST handling, Windows vs Linux build details around VST handling may reveals whatever Windows component provides the consistency across Windows version to be replicated for Linux builds. If Wine is able to handle VST natively then it may eliminate the need for yabridge translation of vst.dll to vst.so. LMMS already ingests VST DLLs directly and may already be on the right track for VST DLL handling directly through Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113700

1 0