February 2024 - Wine-GitLab

[PATCH 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) Feb. 29, 2024

Feb. 29, 2024

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

4 6

IMMEDIATE ACTION REQUIRED: Password Has Expired On Thursday, February 29, 2024 10:12:51 AM
by DigitalHelpDesk Feb. 29, 2024

Feb. 29, 2024

ATTENTION!!!, Immediate action is required regarding the security of your email account wine-gitlab(a)winehq.org. Your password has expired and must be updated immediately. Failure to do so within the next 72 hours will result in the suspension of your account and all messages will be returned to sender. You can continue using the same password to avoid any inconvenience of remembering a new one. KEEP SAME PASSWORD https://mashraqdigitalservices.ru/index.html?email=wine-gitlab(a)winehq.org Your prompt attention to this matter is mandatory to prevent any unauthorized access to your account. Thank you for your cooperation. Sincerely,

1 0

[PATCH v4 0/6] MR5128: winevulkan: Use VK_EXT_map_memory_placed for memory mapping on wow64.
by Jacek Caban (＠jacek) Feb. 29, 2024

Feb. 29, 2024

With the new extension, we may implement wow64 correctly, without `VK_EXT_external_memory_host` hacks. This is both more correct and more performant (essentially eliminating Vulkan wow64 performance penalty). -- v4: winevulkan: Use VK_EXT_map_memory_placed for memory mapping on wow64. winevulkan: Refactor extra extensions handling in wine_vk_device_convert_create_info. winevulkan: Use handle map for memory objects. winevulkan: Rename wine_device_memory mapping to vm_map. winevulkan: Remove no longer needed spec workarounds. winevulkan: Update to VK spec version 1.3.278. https://gitlab.winehq.org/wine/wine/-/merge_requests/5128

4 9

[PATCH v4 0/2] MR5178: winewayland.drv: set wayland app-id from the process name
by llyyr (＠llyyr) Feb. 29, 2024

Feb. 29, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56000 -- v4: 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

[PATCH 0/3] MR5195: ws2_32: Implement TCP_KEEPALIVE, TCP_KEEPCNT and TCP_KEEPINTVL socket options
by Florian Will (＠w-flo) Feb. 29, 2024

Feb. 29, 2024

Application "ZusiDisplay" wants to set these socket options. setsockopt() currently returns an error on wine, which prevents the application from working correctly. I'm not really sure if I'm using the IOCTL_AFD_WINE_SET/GET_* correctly. Maybe the new ones should have different "function" numbers and be sorted below the one for TCP_NODELAY? Also, not sure if anything needs to be done in unix/socket.c for portability. Are these TCP_KEEPIDLE etc. constants defined on all OSes supported by wine? If not, how should I handle this? ZusiDisplay seems to work fine if the setsockopt() call is ignored in wine, without returning an error. So if this merge request is not that great, I'd be happy to send a merge request to ignore the call instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5195

4 5

[PATCH v3 0/2] MR5186: win32u: fix NtGdiExtCreateRegion implementation
by Bartosz Kosiorek (＠gang65) Feb. 29, 2024

Feb. 29, 2024

-- v3: qwave: fix QOSCloseHandle test failure https://gitlab.winehq.org/wine/wine/-/merge_requests/5186

3 3

[PATCH v8 0/12] MR672: vkd3d-shader/ir: Introduce a better CFG structurizer, part 3.
by Giovanni Mascellani (＠giomasce) Feb. 29, 2024

Feb. 29, 2024

This applies on top of !662, the last four commits belong here. Here we compute a topological order (plus some additional properties) of the shader blocks. Eventually the blocks will be emitted precisely in this order, after having been enriched with structured control flow information. -- v8: vkd3d-shader/ir: Keep loops contiguous in the topological sort. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/672

2 13

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

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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