September 2024 - Wine-GitLab

Re: [PATCH v2 0/7] MR6565: dplayx, dpwsockx: Open() part 3. - approved
by Alexandre Julliard (＠julliard) Sept. 26, 2024

Sept. 26, 2024

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6565

1 0

[PATCH v4 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. -- v4: 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 2

[PATCH v3 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. -- v3: 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 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