March 2025 - Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR7460: propsys/tests: Add broken for unexpected value in windows 7.
by Bernhard Übelacker March 3, 2025

March 3, 2025

Tests show test propsys:propsys is failing for many Windows 7 machines. https://test.winehq.org/data/patterns-tb-win.html#propsys:propsys It looks like windows 7 processes VT_R4 like VT_R8. (`0.125f / 0x3e000000 (float/4 byte)` becomes `5.1392085562440189e-315 / 0x3e000000 (double/8 byte)`. Is this worth the effort to remove the failures from the test patterns page? -- v2: propsys/tests: Add broken for unexpected value in windows 7. https://gitlab.winehq.org/wine/wine/-/merge_requests/7460

2 4

Re: [PATCH v26 0/1] MR6884: Iphlpapi.dll: Included SendARP
by Huw Davies (＠huw) March 3, 2025

March 3, 2025

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`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884#note_96536

1 0

[PATCH v4 0/6] MR7250: ntdll: Properly implement NtFlushProcessWriteBuffers (try 2).
by Jinoh Kang (＠iamahuman) March 3, 2025

March 3, 2025

Supersedes !741. On macOS 10.14+ `thread_get_register_pointer_values` is called on every thread of the process. On Linux 4.14+ `membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED, ...)` is used. On x86 Linux <= 4.13 and on other platforms it falls back to calling `NtGetContextThread()` on each thread. The fast path patches from @tmatthies are slightly modified in the following ways: 1. On unsupported platforms, the `try_*()` functions return `FALSE` instead of `0`. 2. `try_exp_membarrier()` is called first, then `try_mach_tgrpvs()`. --- Known applications fixed by this MR: - osu! (rhythm game) song selection menu stuttering - .NET CoreCLR GC - HotSpot JVM (-XX:+UseSystemMemoryBarrier) safepoints -- v4: kernel32/tests: Add a store buffering litmus test involving FlushProcessWriteBuffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/7250

3 8

Re: [PATCH v2 0/1] MR7459: windowscodecs: Add support for WICBitmapTransformRotate270.
by Jinoh Kang (＠iamahuman) March 3, 2025

March 3, 2025

On Mon Mar 3 11:04:01 2025 +0000, Jinoh Kang wrote: > My two cents: > This PR is a no-op change except for the test. While this PR improves > readability a little, I guess we could go further and handle flip > horz/vert flags in a more readable way if we want to go that direction? > (Otherwise just keeping the test should be fine too.) In any case, the commit message is misleading and should be reworded on commit. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7459#note_96526

1 0

Re: [PATCH v2 0/1] MR7459: windowscodecs: Add support for WICBitmapTransformRotate270.
by Jinoh Kang (＠iamahuman) March 3, 2025

March 3, 2025

On Mon Mar 3 08:08:34 2025 +0000, Dmitry Timoshkov wrote: > It looks like you are right, new tests actually pass with current > implementation. Although the patch makes support for > WICBitmapTransformRotate270 more explicit I'm not opposed to leave the > code intact. I'm open to suggestions. My two cents: This PR is a no-op change except for the test. While this PR improves readability a little, I guess we could go further and handle flip horz/vert flags in a more readable way if we want to go that direction? (Otherwise just keeping the test should be fine too.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7459#note_96525

1 0

[PATCH v5 0/1] MR7439: winedmo: Find mp3 stream info if channel data is missing.
by Brendan McGrath (＠redmcg) March 3, 2025

March 3, 2025

This fixes missing mp3 channel data in the FFmpeg demuxer. -- v5: winedmo: Call avformat_find_stream_info for the mp3 format. https://gitlab.winehq.org/wine/wine/-/merge_requests/7439

3 3

[PATCH v4 0/1] MR7439: winedmo: Find mp3 stream info if channel data is missing.
by Brendan McGrath (＠redmcg) March 3, 2025

March 3, 2025

This fixes missing mp3 channel data in the FFmpeg demuxer. -- v4: winedmo: Call avformat_find_stream_info for the mp3 format. https://gitlab.winehq.org/wine/wine/-/merge_requests/7439

3 2

Re: [PATCH v3 0/1] MR7439: winedmo: Find mp3 stream info if channel data is missing.
by Brendan McGrath (＠redmcg) March 3, 2025

March 3, 2025

Brendan McGrath (@redmcg) commented about dlls/winedmo/unix_demuxer.c: > } > format = demuxer->ctx->iformat; > > - if ((params->duration = get_context_duration( demuxer->ctx )) == AV_NOPTS_VALUE) > + if ((params->duration = get_context_duration( demuxer->ctx )) == AV_NOPTS_VALUE || > + strstr( format->name, "mp3")) > { > if ((ret = avformat_find_stream_info( demuxer->ctx, NULL )) < 0) > { > ERR( "Failed to find stream info, error %s.\n", debugstr_averr(ret) ); > goto failed; > } > - params->duration = get_context_duration( demuxer->ctx ); > + if (params->duration == AV_NOPTS_VALUE) > + params->duration = get_context_duration( demuxer->ctx ); @rbernon I wasn't sure how harmless/harmful this assignment was, so I added a check just in case. If you think it's unnecessary I'll remove. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7439#note_96517

1 0

[PATCH v2 0/1] MR7439: winedmo: Find mp3 stream info if channel data is missing.
by Brendan McGrath (＠redmcg) March 3, 2025

March 3, 2025

This fixes missing mp3 channel data in the FFmpeg demuxer. -- v2: winedmo: Find mp3 stream info if channel data is missing. https://gitlab.winehq.org/wine/wine/-/merge_requests/7439

3 5

[PATCH v9 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) March 3, 2025

March 3, 2025

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v9: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

3 4