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
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
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
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
--
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
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
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
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