March 2024 - Wine-gitlab - list.winehq.org

[PATCH v4 0/6] MR5120: mfreadwrite/reader: Implement source reader decoder / video processor pipelines.
by Rémi Bernon 01 Mar '24

01 Mar '24

-- v4: mfreadwrite/reader: Implement IMFSourceReaderEx_GetTransformForStream. mfreadwrite/reader: Create and append a converter transform. mfreadwrite/reader: Keep the stream transforms in a list. mfreadwrite/reader: Call SetOutputType directly on the decoder transform. mf/topology_loader: Only propagate some media type attributes. mfreadwrite/reader: Split source_reader_create_decoder_for_stream helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/5120

3 9

[PATCH v13 0/4] MR4551: Server-side thread priorities implementation (Part 1)
by Marc-Aurel Zent (＠mzent) 01 Mar '24

01 Mar '24

This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on. ~~I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).~~ A few tiny changes ~~(with the ready variable for example)~~ are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change. Since this is a rather large MR, I hope the split here is appropriate ~~(with the second part being slightly smaller)~~, but I think logically it makes the most sense here. -- v13: server: Check wineserver privileges on init with -20 niceness. server: Use setpriority to update thread niceness when safe. ntdll: Set RLIMIT_NICE to its hard limit. server: Introduce new set_thread_priority helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/4551

4 6

[PATCH 0/1] MR5203: webservices/tests: Fix -Warray-bounds warning on gcc 13.2.0.
by Connor McAdams (＠cmcadams) 01 Mar '24

01 Mar '24

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

2 1

[PATCH 0/5] MR5202: d3dx9: Refactor D3DXLoadSurfaceFromMemory and fix a few compressed surface bugs.
by Connor McAdams (＠cmcadams) 01 Mar '24

01 Mar '24

This is the first set of patches in an effort to create more generic image loading/conversion code that can eventually be shared. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5202

3 6

[PATCH v3 0/6] MR5120: mfreadwrite/reader: Implement source reader decoder / video processor pipelines.
by Rémi Bernon 01 Mar '24

01 Mar '24

-- v3: mfreadwrite/reader: Implement IMFSourceReaderEx_GetTransformForStream. mfreadwrite/reader: Create and append a converter transform. mfreadwrite/reader: Keep the stream transforms in a list. mfreadwrite/reader: Call SetOutputType directly on the decoder transform. mf/topology_loader: Only propagate some media type attributes. mfreadwrite/reader: Split source_reader_create_decoder_for_stream helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/5120

3 10

[PATCH 0/1] MR5022: Draft: d3dx10: Add support for creating textures from DXGI_FORMAT_B4G4R4A4_UNORM DDS files.
by Connor McAdams (＠cmcadams) 01 Mar '24

01 Mar '24

Yakuza 6's Puyo Puyo minigame creates a texture from a DDS file that is the equivalent format of `DXGI_FORMAT_B4G4R4A4_UNORM`, which windowscodecs does not support. This patch converts the texture into the equivalent of `DXGI_FORMAT_R8G8B8A8_UNORM` DDS file at the start of `load_texture_data()`, which allows us to avoid having an entirely separate code path for this specific image type. This current patch just handles the most basic of DDS files, if this approach seems reasonable I will flesh it out more, I just wanted to see if it was a good/bad idea before putting anymore work into it. :) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5022

3 5

[PATCH v6 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) 01 Mar '24

01 Mar '24

Test module references created by resolving forwarded exports. The following diagram explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition. --- ### Alternative options 1. Find existing DLLs satisfying this scenario: I haven't found any in wine tree. Let me know if I missed anything. 2. Construct PE for the DLLs on-the-fly: This sounds more complicated than a handful of test DLLs. -- v6: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

5 9

[PATCH 0/7] MR5138: winegstreamer: Support and expose generic audio/video MFT decoders.
by Rémi Bernon 01 Mar '24

01 Mar '24

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

3 22

[PATCH v4 0/1] MR5157: evr/dshow: List NV12 as supported, improve warnings
by David Gow (＠sulix) 01 Mar '24

01 Mar '24

Add support for NV12 to ``evr_render()``, as otherwise no video is rendered at all in games like Age of Empires II DE (see: https://github.com/ValveSoftware/Proton/issues/3189#issuecomment-1962984985) Interestingly, this doesn't result in NV12 data being passed to ``evr_copy_sample_buffer()`` as I suspected, so the RGB32 copying code seems to work fine. Nevertheless, add a warning if we get an unknown format in ``evr_copy_sample_buffer()``, as that could potentially lead to nasty memory issues (e.g., if we get the width/lines/stride wrong). I confess, I don't really understand what's going on here: the format of the video is definitely ``MFVideoFormat_NV12`` in ``evr_render()``, but I never see any attempt to use NV12 in ``evr_copy_sample_buffer()`` — it's always ``MFVideoFormat_RGB32``. For that reason, I've also not tried to write any tests here — I don't know the MF API well enough to plumb this all the way through. On the bright side, though, the fact that everything mysteriously ends up as RGB32 means I haven't had to write an NV12 codepath for ``evr_copy_sample_buffer()`` — I'm not sure exactly how to handle the multi-plane formats there. -- v4: evr/dshow: Support NV12 in evr_render https://gitlab.winehq.org/wine/wine/-/merge_requests/5157

2 2

[PATCH v6 0/2] MR5178: winewayland.drv: set wayland app-id from the process name
by llyyr (＠llyyr) 01 Mar '24

01 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56000 -- v6: winewayland.drv: Implement SetWindowText. winewayland.drv: Set wayland app-id from the process name. https://gitlab.winehq.org/wine/wine/-/merge_requests/5178

3 8