March 2025 - wine-gitlab

[PATCH v4 0/8] MR7432: mp3dmod: Add future support for Float encoding and fix various discrepancies with Windows
by Brendan McGrath (＠redmcg) 04 Mar '25

04 Mar '25

This MR adds the ability to support float encoding (which will be used by the IMFTransform interface). It also adds tests and addresses a number of small discrepancies discovered between the Wine and native implementation. -- v4: mp3dmod: Ensure nChannels is greater than zero on input. mp3dmod/tests: Add test for nChannels = 0 on input. mp3dmod: Only allow 1/2 and 1/4 subsampling. mp3dmod: Return error if requested output format values don't agree. mp3dmod/tests: Test different output sample rates. mp3dmod: Add support for 32-bit sample size. mp3dmod/tests: Add test for 32-bit sample size. mp3dmod: Return S_OK in Allocate/Free Resources. https://gitlab.winehq.org/wine/wine/-/merge_requests/7432

3 10

[PATCH 0/1] MR3131: gdiplus: Fix gif shows misplaced.
by Jiajin Cui (＠jin-king1) 04 Mar '25

04 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54271 Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3131

3 6

[PATCH v32 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 04 Mar '25

04 Mar '25

Current code requires entering a newline character in order to continue past DIR /P prompts. This change allows any key to be pressed instead. Code to handle this was similar to existing WCMD_pause() so we leveraged that code for this purpose as well. Key to the fix was the removal of ENABLE_LINE_INPUT from the console flags, and ENABLE_PROCESSED_INPUT was added in order to preserve the ability to abort the operation via Ctrl-C. -- v32: cmd: Allow any key to continue past DIR /P pauses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7400

2 2

[PATCH v3 0/7] MR7432: mp3dmod: Add future support for Float encoding and fix various discrepancies with Windows
by Brendan McGrath (＠redmcg) 04 Mar '25

04 Mar '25

This MR adds the ability to support float encoding (which will be used by the IMFTransform interface). It also adds tests and addresses a number of small discrepancies discovered between the Wine and native implementation. -- v3: mp3dmod: Ensure nChannels is greater than zero on input. mp3dmod/tests: Add test for nChannels = 0 on input. https://gitlab.winehq.org/wine/wine/-/merge_requests/7432

3 9

[PATCH 0/1] MR7281: include: Prefer builtin atomics on x86 unless known broken.
by William Horvath (＠whrvt) 04 Mar '25

04 Mar '25

Clang presents as GCC 4.2.1, so it was always using the fallbacks for `InterlockedExchange{,Pointer}` on the non-PE side. The fix for the GCC `__atomic_*` bug linked in the comment for the `__WINE_ATOMIC_*` macros first appeared in GCC 8: https://github.com/gcc-mirror/gcc/commit/d8c40eff56f69877b33c697ded756d50fd… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7281

3 6

[PATCH v3 0/2] MR7119: ntdll, loader: Add __attribute__((used)) to a few symbols that shouldn't be discarded.
by William Horvath (＠whrvth) 04 Mar '25

04 Mar '25

These changes are enough to allow building the entirety of the native (ELF) side with `-flto`. -- v3: loader: Mark thread_ldt, thread_data, wld_start "used". ntdll: Mark call_init_thunk and abort_thread "used". https://gitlab.winehq.org/wine/wine/-/merge_requests/7119

4 5

Re: [PATCH v26 0/1] MR6884: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) 03 Mar '25

03 Mar '25

On Mon Mar 3 23:25:58 2025 +0000, Huw Davies wrote: > It would be better to implement `SendARP()` in terms of `ResolveIpNetEntry2()`. > Further, `ResolveIpNetEntry2()` should likely use the `Nsi` functions to > retrieve the neighbour info from `nsiproxy`. I think I saw ResolveIpNetEntry2() function documentation in the past. Maybe because I could not find sources(help please), end up not using it. Or I asked somebody. Not sure. Does ResolveIpNetEntry2() need linux privileges ? Thanks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884#note_96714

1 0

[PATCH 0/1] MR7461: remove "Broken NVIDIA RandR detected" error line
by Andrey Zhukov (＠HP) 03 Mar '25

03 Mar '25

I am proposing to do something about the "Broken NVIDIA RandR detected" error line, i think that this error serves no good purpose. Motivation: * fallback Firstly, if wine merely switches to a fallback in case of a problem - that's not an error, that's an expected and handled issue that is successfully worked around. If there are potential issues with the workaround - that's what should be noted. Programs run with wine do work well (enough) when this "error" is present. I do understand that you can change certain settings to change the codepath so that this error to not appear, is this actually necessary to fix an actual problem? Sending someone on a path to fix this "error" when the program they're running is working perfectly well is not a great thing. * calling it an error More commonly, wine output is ignored when everything is running correctly, and only looked at when problems arise, so if you log an "error" around the time that a different issue happens it is reasonable to assume that the user will treat the error as the cause of the problem. So we end up with lots of threads like this: https://forum.winehq.org/viewtopic.php?t=32583 quote: "Please don't title a forum thread with:Broken NVIDIA RandR detected, falling back to RandR 1.0. **This is totally meaningless and does not provide any description - what-so-ever - of what the thread is about. ** Wine outputs this terminal message, for anyone using the Nvidia proprietary driver. Whether they have a crappy, ancient video card or a shiny new Geforce RTX 2080 Ti ! **I patch out this warning message, on my Gentoo wine ebuild's, because it is so annoying.** * error spam So it confuses inexperienced users very much. I shouldn't have to point out the search engine keyword irrelevancy. But even for experienced users (the quoted user uses gentoo), it is annoying enough to patch out. If the quoted example wasn't enough here's a random pastebin from 2022 i found removing the line: https://pastebin.com/6auSsL4B, and i've got at least one personal example of someone patching the error out. It is repeated just too frequently. Spam makes reading more important errors harder too. * recommending nouveau This line is in a codepath commonly used in games. Recommending nouveau to usually inexperienced linux users - gamers is a horrible idea. Don't get me wrong, i'm all for a free solution, i'd love for nouveau to be just as good, but it is simply not. For a user without a reasonable understanding of linux a messup with video drivers costs a complete reinstall. Mindshare of free software is probably out of scope for wine, but i'm sure we can agree there's some general value there. There is a wiki entry about this error: https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#broken-nvidia-randr-detecte… It all generally makes sense, and if you read it carefully it does say "for users who do not need the proprietary driver", but for an inexperienced user that's an encouragement that assumes they do not in fact need the proprietary driver. Also if you do understand what RandR is you're likely to understand that a program not launching for example probably isn't related to the "error", though i think even a knowing user would still consider it a possibility. * keywords used The workaround described under that is of legitemate value, but i think the correlation between the "error" keywords and the actual problematic behavior is not great. If we wish to point the user towards the workaround the line should be something along the lines of "program starts fullscreen at low resolution". * code I am not a maintainer and am not experienced enough to just pick up a codebase like this, so i'll start off with admitting i don't really know the specifics of the code. But just by looking at it, the comment on line 511 in dlls/winex11.drv/xrandr.c says that the check that causes the "error" line to print just checks if the driver is nvidia? Isn't that not even checking the specific behavior that it supposedly doesn't implement? (if it was fixed since that code was written) Proposed solutions: Plain and simple - delete the line. This would solve all the problems mentioned above, perhaps with the exception of >keywords used. This pull request. Change the message type to debug or trace or similar. This would address >calling it an error Only print error on first use of function or in startup. This would address >error spam -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7461

4 5

[PATCH 0/6] MR7436: d3dx9: More changes to D3DXSaveSurfaceToFileInMemory().
by Connor McAdams (＠cmcadams) 03 Mar '25

03 Mar '25

This patch series reworks `D3DXSaveSurfaceToFileInMemory()` to use the new `d3dx_save_pixels_to_memory()` function. It also adds support for selecting a replacement pixel format when the image file format being saved to doesn't have direct support for the pixel format being saved. The code for calculating the best replacement format was inspired by the code in `check_texture_requirements()` in `d3dx9_36/texture.c`. This should fix WineHQ bug 51584, but I haven't tested that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7436

3 11

[PATCH v4 0/10] MR7407: windowscodecs: Implement query strings enumerator.
by Nikolay Sivov (＠nsivov) 03 Mar '25

03 Mar '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v4: windowscodecs: Implement GetPreferredVendorGUID(). windowscodecs/metadata: Implement GetClassID(). windowscodecs/tests: Add some tests for metadata handler GetClassID(). windowscodecs/metadata: Replicate original stream position when creating writer instances from readers. windowscodecs/metadata: Restore original stream position on GetStream(). windowscodecs/tests: Add some tests for stream position handling when nested readers are used. windowscodecs: Implement CreateQueryWriterFromReader(). windowscodecs/metadata: Do not decorate 'wstr' items with a type name in returned queries. windowscodecs/tests: Add some more tests for query enumeration. windowscodecs: Implement query strings enumerator. https://gitlab.winehq.org/wine/wine/-/merge_requests/7407

3 14

2025

2024

2023

2022

wine-gitlab March 2025