- wine-gitlab - winehq.org

[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

1 0

[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

[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

[PATCH 0/1] MR6980: mscoree: Use correct variable for codebase path.
by Esme Povirk (＠madewokherd) 07 Dec '24

07 Dec '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57241 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6980

2 1

[PATCH v3 0/5] MR6944: winex11: Workaround KWin bug with maximized windows.
by Rémi Bernon (＠rbernon) 07 Dec '24

07 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 -- v3: winex11: Workaround KWin bug with maximized windows. winex11: Keep track of the window manager name. winex11: Keep track of the _NET_SUPPORTING_WM_CHECK window. winex11: Listen to root window _NET_SUPPORTED property changes. winex11: Move the _NET_SUPPORTED information to the thread data. https://gitlab.winehq.org/wine/wine/-/merge_requests/6944

3 7

[PATCH v2 0/1] MR6938: Draft: winewayland.drv: Implement support for xdg-toplevel-icon.
by Etaash Mathamsetty (＠etaash.mathamsetty) 07 Dec '24

07 Dec '24

-- v2: winewayland.drv: Implement support for xdg-toplevel-icon. https://gitlab.winehq.org/wine/wine/-/merge_requests/6938

3 2

2025

2024

2023

2022

wine-gitlab