December 2024 - Wine-gitlab

[PATCH v4 0/17] MR6944: Draft: winex11: Workaround KWin bug with maximized windows.
by Rémi Bernon 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 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

[PATCH v2 0/3] MR6959: d2d1: Implement d2d_device_GetDxgiDevice().
by Zhiyi Zhang (＠zhiyi) 07 Dec '24

07 Dec '24

For React Native. -- v2: d2d1: Implement d2d_device_GetDxgiDevice(). d2d1: Remove an unnecessary cast in d2d_device_context_init(). d2d1/tests: Add ID2D1Device2_GetDxgiDevice() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/6959

3 8

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Robbert van der Helm (＠robbert-vdh) 07 Dec '24

07 Dec '24

On Mon Dec 2 22:41:17 2024 +0000, Rémi Bernon wrote: > There has been various changes in the way we handle window positioning, > and it's now probably more flexible to arbitrary X11 parent windows, but > in any case we still always consider the X root window coordinates as > the origin for the Win32 desktop. > If you want to embed all Wine windows into another window and use its > position as the Win32 desktop origin, it's basically what the "virtual > desktop" mode is doing already. It's an option in winecfg, where we > create a dedicated window for the Win32 desktop and every Wine window > will be a child of it. You could probably then reparent the desktop > window to the window you want? 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? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_90101

1 0