September 2024 - Wine-GitLab

[PATCH v2 0/2] MR6569: Draft: winex11: Keep a list of pending window config requests.
by Rémi Bernon Sept. 26, 2024

Sept. 26, 2024

Instead of a single configure serial, which is simply not enough to mitigate event feedback loops. This should (hopefully) address the recent d3d8:device / d3d9:device test failures on the Gitlab CI, without having to add more `flush_events` calls to the tests. I believe it should also provide a more general fix to this race condition than the configure_serial mechanism. -- v2: winex11: Also discard near-matching configs with similar sizes. winex11: Keep a list of pending window config requests. https://gitlab.winehq.org/wine/wine/-/merge_requests/6569

1 3

[PATCH 0/2] MR6569: Draft: winex11: Keep a list of pending window config requests.
by Rémi Bernon Sept. 26, 2024

Sept. 26, 2024

Instead of a single configure serial, which is simply not enough to mitigate event feedback loops. This should (hopefully) address the recent d3d8:device / d3d9:device test failures on the Gitlab CI, without having to add more `flush_events` calls to the tests. I believe it should also provide a more general fix to this race condition than the configure_serial mechanism. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569

2 4

[PATCH v3 0/6] MR6560: winewayland: Use subsurfaces for unmanaged windows.
by Rémi Bernon Sept. 26, 2024

Sept. 26, 2024

-- v3: winewayland: Use subsurfaces for unmanaged windows. winewayland: Introduce a new update_wayland_surface_state_toplevel helper. winewayland: Introduce a new wayland_surface_reconfigure_xdg helper. winewayland: Introduce a new wayland_surface role enumeration. winewayland: Call wayland_surface_clear_role in wayland_surface_destroy. winewayland: Move surface title change to wayland_surface_make_toplevel. https://gitlab.winehq.org/wine/wine/-/merge_requests/6560

3 10

[PATCH 0/7] MR6565: dplayx, dpwsockx: Open() part 3.
by Anton Baskanov (＠baskanov) Sept. 26, 2024

Sept. 26, 2024

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

4 9

[PATCH v2 0/4] MR6566: user32/tests: Add tests for monitor DPI scaling and virtual display settings.
by Rémi Bernon Sept. 26, 2024

Sept. 26, 2024

The tests show how recent Windows use per-monitor DPI to implement virtual display settings. This is only the case on the w11pro64_nv and w11pro64_amd virtual machines, and the other VMs only support per-monitor DPI scaling. Both these two scaling add up, and their effect is exposed by the GetDpiForMonitorInternal call, with the ANGULAR and RAW dpi flavors. -- v2: user32/tests: Add tests with windows and monitor DPI scaling. user32/tests: Add more tests with display source DPI scaling. user32/tests: Add more tests for GetDpiForMonitorInternal. user32: Stub DisplayConfigSetDeviceInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/6566

1 5

[PATCH 0/4] MR6566: user32/tests: Add tests for monitor DPI scaling and virtual display settings.
by Rémi Bernon Sept. 26, 2024

Sept. 26, 2024

The tests show how recent Windows use per-monitor DPI to implement virtual display settings. This is only the case on the w11pro64_nv and w11pro64_amd virtual machines, and the other VMs only support per-monitor DPI scaling. Both these two scaling add up, and their effect is exposed by the GetDpiForMonitorInternal call, with the ANGULAR and RAW dpi flavors. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6566

1 4

Re: [PATCH v2 0/6] MR6560: winewayland: Use subsurfaces for unmanaged windows.
by Alexandros Frantzis (＠afrantzis) Sept. 26, 2024

Sept. 26, 2024

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/window.c: > /* Get the managed state with win_data unlocked, as is_window_managed > * may need to query win_data information about other HWNDs and thus > * acquire the lock itself internally. */ > - managed = is_window_managed(hwnd, swp_flags, &new_rects->window); > + if (!(managed = is_window_managed(hwnd, swp_flags, &new_rects->window)) && surface) > + { > + toplevel = NtUserGetWindowRelative(hwnd, GW_OWNER); > + if (toplevel) toplevel = NtUserGetAncestor(toplevel, GA_ROOT); > + /* fallback to any window that is right below our top left corner */ > + if (!toplevel) toplevel = NtUserWindowFromPoint(new_rects->window.left - 1, new_rects->window.top - 1); If I am reading the docs correctly `NtUserWindowFromPoint()` can return child windows in which case anchoring won't work. If we move this above the `NtUserGetAncestor(toplevel, GA_ROOT)` a couple of lines above we will we get a proper toplevel in all cases. Are there any downsides to this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83412

1 0

Re: [PATCH v2 0/6] MR6560: winewayland: Use subsurfaces for unmanaged windows.
by Alexandros Frantzis (＠afrantzis) Sept. 26, 2024

Sept. 26, 2024

On Thu Sep 26 07:05:10 2024 +0000, Alexandros Frantzis wrote: > The core problem seems to be that in > `wayland_win_data_update_wayland_state` `surface->role` is used to > determine what's the *current* role for the surface. However > `surface->role` is really tracking what role was given in the past to > this surface and thus can be given again in the future (because surfaces > cannot change roles). > In this particular osu! case, we have a previously toplevel surface (so > surface->role = toplevel) that is now role-less, but > `wayland_surface_update_state_toplevel` is called on it, which then > unconditionally tries to access the NULL xdg_toplevel and crashes the > thread while holding the 'win_data_mutex` lock. One fix is to add `if (!surface->xdg_toplevel) return;` at the beginning of `wayland_surface_update_state_toplevel()`. It depends on what we want `surface->role` to mean. If it is "possible role" (which seems to match how other parts of the code are implemented) then this should be OK. Alternatively, perhaps a more explicit arrangement `surface->role` vs `surface->possible_role` would make things clearer? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83411

1 0

Re: [PATCH v2 0/6] MR6560: winewayland: Use subsurfaces for unmanaged windows.
by Alexandros Frantzis (＠afrantzis) Sept. 26, 2024

Sept. 26, 2024

On Thu Sep 26 06:38:50 2024 +0000, William Horvath wrote: > It starts occurring after commit 5/6 (af65d37c Introduce > update_wayland_surface_state_toplevel). Reverting to the previous commit > 4/6, 35c90946 Introduce wayland_surface_reconfigure_xdg, it behaves normally. The core problem seems to be that in `wayland_win_data_update_wayland_state` `surface->role` is used to determine what's the *current* role for the surface. However `surface->role` is really tracking what role was given in the past to this surface and thus can be given again in the future (because surfaces cannot change roles). In this particular osu! case, we have a previously toplevel surface (so surface->role = toplevel) that is now role-less, but `wayland_surface_update_state_toplevel` is called on it, which then unconditionally tries to access the NULL xdg_toplevel and crashes the thread while holding the 'win_data_mutex` lock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83410

1 0

Re: [PATCH v2 0/6] MR6560: winewayland: Use subsurfaces for unmanaged windows.
by William Horvath (＠whrvth) Sept. 26, 2024

Sept. 26, 2024

On Thu Sep 26 06:15:21 2024 +0000, Aida Jonikienė wrote: > Can you try bisecting the individual MR commits? :frog: It starts occurring after commit 5/6 (af65d37c Introduce update_wayland_surface_state_toplevel). Reverting to the previous commit 4/6, 35c90946 Introduce wayland_surface_reconfigure_xdg, it behaves normally. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83409

1 0