December 2024 - wine-gitlab

[PATCH 0/1] MR6985: win32u: Release the Win16 mutex when yielding in peek_message.
by Rémi Bernon (＠rbernon) 09 Dec '24

09 Dec '24

This is important for other Win16 threads to have a chance to execute during peek_message, even if no messages are received, or if the thread is within a nested window message procedure call. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57384 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6985

3 2

[PATCH 0/3] MR6986: mf: Fix a regression in unexpected source shutdown handling.
by Conor McCarthy (＠cmccarthy) 09 Dec '24

09 Dec '24

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

3 4

[PATCH v4 0/17] MR6944: Draft: winex11: Workaround KWin bug with maximized windows.
by Rémi Bernon (＠rbernon) 09 Dec '24

09 Dec '24

I know we've had a policy to avoid window manager specific workarounds, I think we could reconsider it. The fix could be unguarded and applied with every window manager, and could very well work, but I think it is ugly enough to justify checking for KWin specifically. The problem is that as soon as a window configure request is sent to a maximized window, KWin internal state gets bogus and it loses track of the window maximized state. I've described the KWin source details on https://bugs.kde.org/show_bug.cgi?id=496966 and opened https://invent.kde.org/plasma/kwin/-/merge_requests/6854 as a possible fix for it, but the time it will take to land could justify working around it in Wine. The workaround is to avoid sending configure requests to maximized windows, which sounds sensible and we already avoid resizing maximized windows, but, moving a maximized window to a different monitor *requires* sending a configure request. KWin bug makes no difference to requests with only position changes, and they trigger it all the same. So, the only solution is to temporarily remove the maximized state bits before sending the configure request, putting them back afterwards. This is quite straightforward to do with the new state tracker, but it could very well trigger other problems with other window managers. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57465 -- v4: winex11: Workaround KWin bug with maximized windows. winex11: Set _NET_WM_USER_TIME to 0 to implement SWP_NOACTIVATE. winex11: Keep track of the SWP flags to be used when mapping windows. winex11: Keep _NET_WM_USER_TIME on the individual windows. winex11: Workaround Mutter bug when changing decorations. winex11: Avoid creating windows with override-redirect flag set. winex11: Track _MOTIF_WM_HINTS property in the state tracker. winex11: Introduce a new handle_state_change helper. winex11: Ignore transient state changes in other processes. winex11: Give focus to the expected window when unampping with focus. winex11: Use the current state when deciding how to reply to WM_TAKE_FOCUS. winex11: Use the state tracker for the desktop window _NET_WM_STATE. win32u: Use the winstation monitor update serial to detect updates. server: Add a winstation monitor update serial counter. win32u: Extend display_lock CS around winstation check. win32u: Release the Win16 mutex when yielding in peek_message. win32u: Skip updating the cache on driver load if we're already updating it. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6944

1 0

[PATCH 0/1] MR6984: msvcrt: Don't leak find handle or error in _findfirst().
by Piotr Caban (＠piotr) 09 Dec '24

09 Dec '24

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

2 1

[PATCH 0/1] MR6981: ucrtbase/tests: use correct size to GetEnvironmentVariableW
by Marcus Meissner (＠msmeissn) 09 Dec '24

09 Dec '24

Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6981

3 2

[PATCH 0/1] MR6979: webservices: Rename a struct member from bool to boolean
by Gerald Pfeifer (＠gerald) 09 Dec '24

09 Dec '24

bool is a reserved identifier in C23 so we would break with GCC 15 moving to -std=gnu23 (which is based on C23). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6979

3 3

[PATCH 0/1] MR6982: winebth.sys: Fix new bluetooth events being incorrect set due to variable shadowing.
by Vibhav Pant (＠vibhavp) 09 Dec '24

09 Dec '24

(Reported by Coverity) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6982

3 2

[PATCH v2 0/1] MR6982: winebth.sys: Fix new bluetooth events being incorrect set due to variable shadowing.
by Vibhav Pant (＠vibhavp) 09 Dec '24

09 Dec '24

(Reported by Coverity) -- v2: winebth.sys: Fix new bluetooth events being incorrect set due to variable shadowing. https://gitlab.winehq.org/wine/wine/-/merge_requests/6982

2 1

[PATCH 0/2] MR6956: mfplat: Add support for audio with NULL format to MFInitMediaTypeFromAMMediaType.
by Brendan McGrath (＠redmcg) 07 Dec '24

07 Dec '24

Includes tests for when MFInitMediaTypeFromAMMediaType is called with major type as audio, and format type as NULL. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6956

4 4

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon (＠rbernon) 07 Dec '24

07 Dec '24

On Sat Dec 7 21:14:33 2024 +0000, Robbert van der Helm wrote: > Embedding the entire virtual desktop window will sadly not work for this > use case. The context here is that professional audio production > software usually lets users use third party synthesizers and effects > through various plugin systems. Those plugins are native shared > libraries that implement one of the various standardized plugin ABIs. > Most of these plugins are only available for Windows and macOS, which > means they can't be loaded on Linux. Yabridge makes it possible to use > these plugins on Linux by acting as both a plugin and a plugin host, and > then passing through any and all function calls made by either the > native host or the Windows plugin so it appears that they're talking to > a regular old native plugin or host. > The thing is that users usually need to interact with those plugins > through a custom GUI provided by the plugin. In all of the common plugin > standards the host provides a native window handle that the plugin then > embeds itself into (reparent on X11, child window on Windows, etc.). So > to make this work, yabridge creates a Win32 window, asks the plugin to > embed itself into that window, and then reparents the X11 window (i.e. > `GetProp(hwnd, "__wine_x11_whole_window")`) into the X11 window provided > by the host. This approach works surprisingly well, except for the > aforementioned mouse coordinate offset thing. In the past yabridge was > able to fix this by directly sending `ConfigureNotify` events to Wine > without actually moving the window so Wine knows where the window is > actually located on screen, but that no longer works with the stricter > implementation from this PR. > So my question is more or less: can we make this behavior work with the > updated winex11 implementation, or would it be feasible to make Wine > aware of this behavior so it would just work without having to inform > Wine where on screen an embedded window is? I don't know for sure but there are probably some ways to make it work. It works already more or less well with embedded systray windows, so maybe doing something similar could be enough. Alternatively mouse input is mapped in `map_event_coords` and we preferred event root/x_root/y_root values when available because it avoided some inconsistencies when moving windows, but window positioning has been refactored lately, and maybe this isn't necessary anymore. Using window-relative mouse input could solve your case too (or we could also perhaps consider a winecfg option to prefer it over absolute positions). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_90107

1 0

2025

2024

2023

2022

wine-gitlab December 2024