February 2024 - wine-gitlab

[PATCH v13 0/2] MR5151: schtasks: Ignore /tr /sc /rl options in create command.
by Vijay Kiran Kamuju (＠infyquest) 29 Feb '24

29 Feb '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47152 This is initial part which ignores the options. -- v13: schtasks: Stub implementation of /sc option in create command. https://gitlab.winehq.org/wine/wine/-/merge_requests/5151

2 2

[PATCH 0/1] MR5183: cmd: Fix calling .bat failure, when filename with inbuilt keyword.
by Haidong Yu (＠yhd986) 29 Feb '24

29 Feb '24

For example, calling start.bat. Signed-off-by: Haidong Yu <yuhaidong(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5183

3 4

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

29 Feb '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. -- v2: evr/dshow: Support NV12 in evr_render https://gitlab.winehq.org/wine/wine/-/merge_requests/5157

2 2

[PATCH v3 0/9] MR4533: winex11: Detach / attach vulkan window surfaces as needed.
by Rémi Bernon (＠rbernon) 29 Feb '24

29 Feb '24

This is some preparatory work for vulkan child window and other features which currently live in Proton. I think this could be upstream already, and it will make rebasing patches on top of it simpler. To get vulkan child window upstream we'd probably still need to rework it a bit and maybe try to move the wait and blit to `vkQueuePresent` somehow. The idea here is also that although Vulkan spec does not allow multiple active swapchains for the same window, Windows tends to allow it especially with D3D, and we also need to support the case where multiple APIs are use to draw onto the same window surface (as we implement D3D on top of GL/Vk for instance). -- v3: winex11: Rename X11DRV_FLUSH_GL_DRAWABLE to X11DRV_PRESENT_DRAWABLE. winex11: Put detached client windows surfaces offscreen. winex11: Re-attach vulkan surfaces when images are acquired. winevulkan: Add vkAcquireNextImage(2)KHR driver entries. winex11: Resize detached vulkan surfaces when window is resized. winex11: Detach the vulkan surfaces when their HWND is destroyed. winex11: Detach vulkan client windows before destroying them. winex11: Introduce a new detach_client_window helper. winex11: Add traces to vulkan surface grab / release. https://gitlab.winehq.org/wine/wine/-/merge_requests/4533

3 34

[PATCH v4 0/1] MR2274: ntdll: Add source file and line to debug traces.
by Rémi Bernon (＠rbernon) 29 Feb '24

29 Feb '24

-- v4: ntdll: Add source and return address information to debug traces. https://gitlab.winehq.org/wine/wine/-/merge_requests/2274

2 3

[PATCH v2 0/4] MR3199: winhttp: Handle SEC_I_RENEGOTIATE after DecryptMessage.
by Rémi Bernon (＠rbernon) 29 Feb '24

29 Feb '24

This is some very old patch series, initially aimed at speeding up Gears of Wars online connection, but it wasn't clear if it was actually necessary. We now confirmed that it is also required for Gears 5 online mode, and without it, connection fails with an error message. I updated the last change to specifically handle TLS rehandshake vs empty input, to avoid breaking some tests. I think having empty input when renegotiating is a valid scenario, although I'm not sure how to write tests for that (it will require some server-side part to request a re-handshake to the client). In any case, this has nothing to do with client certificate as the returned ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED error in the code seems to suggest. -- v2: secur32: Perform TLS re-handshake after SEC_I_RENEGOTIATE was returned. winhttp: Handle SEC_I_RENEGOTIATE after DecryptMessage. winhttp: Introduce new netconn_negotiate helper. winhttp: Move connect end checks out of the loop. https://gitlab.winehq.org/wine/wine/-/merge_requests/3199

4 8

[PATCH v6 0/5] MR2698: winex11: Avoid breaking XIM XFilterEvent / XmbLookupString sequence.
by Rémi Bernon (＠rbernon) 29 Feb '24

29 Feb '24

-- v6: winex11: Avoid breaking XIM sequence when merging mouse motion events. winex11: Avoid breaking XIM sequence when merging ConfigureNotify events. winex11: Introduce new handle_delayed_event helper. winex11: Move call_event_handler function around. winex11: Remove unnecessary process_events helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/2698

2 7

[PATCH v12 0/2] MR5151: schtasks: Ignore /tr /sc /rl options in create command.
by Vijay Kiran Kamuju (＠infyquest) 29 Feb '24

29 Feb '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47152 This is initial part which ignores the options. -- v12: schtasks: Stub implementation of /sc option in create command. https://gitlab.winehq.org/wine/wine/-/merge_requests/5151

3 3

[PATCH v4 0/1] MR5184: winecrt0: Use load config on all targets.
by Jacek Caban (＠jacek) 29 Feb '24

29 Feb '24

Based on mingw-w64. System modules on Windows have load config available. In fact, all applications using the default MSVC for crt have it. mingw-w64 provides the load config, but it also requires linker to use it and currently only LLD supports it. This MR does the same in winecrt0. We will need it on both ARM64 and ARM64EC targets to support ARM64X (which requires LLD for other reasons anyway). -- v4: winebuild: Output load config on PE targets. https://gitlab.winehq.org/wine/wine/-/merge_requests/5184

4 4

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

29 Feb '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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5157

6 12

2025

2024

2023

2022

wine-gitlab February 2024