When opening the Cheat Engine [1] settings window, the window is spawned at around 400x400, making the right and bottom sides of the window inaccessible due to clipping. This commit moves the window to 0x0 to ensure that all window contents on the monitor are accessible.
[1]: https://github.com/cheat-engine/cheat-engine
Signed-off-by: Julian Orth ju.orth@gmail.com
From: Julian Orth ju.orth@gmail.com
When opening the Cheat Engine [1] settings window, the window is spawned at around 400x400, making the right and bottom sides of the window inaccessible due to clipping. This commit moves the window to 0x0 to ensure that all window contents on the monitor are accessible.
[1]: https://github.com/cheat-engine/cheat-engine
Signed-off-by: Julian Orth ju.orth@gmail.com --- dlls/winewayland.drv/window.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dlls/winewayland.drv/window.c b/dlls/winewayland.drv/window.c index acc34a18218..d5ae8f2d597 100644 --- a/dlls/winewayland.drv/window.c +++ b/dlls/winewayland.drv/window.c @@ -615,7 +615,7 @@ static void wayland_configure_window(HWND hwnd) if (needs_enter_size_move) send_message(hwnd, WM_ENTERSIZEMOVE, 0, 0); if (needs_exit_size_move) send_message(hwnd, WM_EXITSIZEMOVE, 0, 0);
- flags |= SWP_NOACTIVATE | SWP_NOZORDER | SWP_NOOWNERZORDER | SWP_NOMOVE; + flags |= SWP_NOACTIVATE | SWP_NOZORDER | SWP_NOOWNERZORDER; if (window_width == 0 || window_height == 0) flags |= SWP_NOSIZE;
style = NtUserGetWindowLongW(hwnd, GWL_STYLE); @@ -634,7 +634,10 @@ static void wayland_configure_window(HWND hwnd) }
SetRect(&rect, 0, 0, window_width, window_height); - OffsetRect(&rect, data->rects.window.left, data->rects.window.top); + rect = window_rect_from_visible(&data->rects, rect); + if (rect.left == data->rects.window.left && rect.top == data->rects.window.top) + flags |= SWP_NOMOVE; + NtUserSetRawWindowPos(hwnd, rect, flags, FALSE); }
Thanks for the MR. Sadly, this approach to work around the win32 virtual screen clipping (due to mismatch between win32 and Wayland positions) was initially proposed as part of https://gitlab.winehq.org/wine/wine/-/merge_requests/4014, but in the end the decision was to not use it. The reasons for this are discussed in the thread at https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581 (TL;DR is that doing this would fix some cases but break other cases).
In terms of what would help us move forward, this is also discussed in the earlier MR, in short:
1. Introduce a mechanism for the drivers to tell Wine to not clip some input events. or 2. Some kind of absolute positioning Wayland protocol (ext-zones seems to be the one discussed lately), so we can keep the positions in sync.
The reasons for this are discussed in the thread at https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581 (TL;DR is that doing this would fix some cases but break other cases).
I had seen that but I don't think there were any actual examples showing anything being broken with this approach.
On Tue Apr 29 12:01:05 2025 +0000, Julian Orth wrote:
The reasons for this are discussed in the thread at
https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581 (TL;DR is that doing this would fix some cases but break other cases). I had seen that but I don't think there were any actual examples showing anything being broken with this approach.
Below are a couple problems I have seen myself (and probably others I am forgetting about). The earlier experimental branch, which also use the "move windows to origin" approach, tried to use some special casing and workarounds for such issues, but the final complexity (and fragility) made the whole effort less enticing compared to some of the other simpler ideas mentioned above.
1. Multi-monitor scenarios are problematic with a simple move to (0,0), especially when combined with fullscreen (since fullscreen is a "state" inferred from window position and size on win32). The (0,0) positioning in the original MR was supposed to be just the first step, since we didn't support multiple monitors then. The experimental branch was tracking which output each surface was on (with enter/leave events), but this turned out to be complex/fragile in terms of syncing etc
2. Applications that are very strong-minded about where they want their windows to be placed, and react with another reposition/resize when we try to position them. A particular problematic case I have seen is in fullscreen or maximized scenarios, with some apps/games insisting that they are sized just a little bit bigger than the target monitor and centering themselves accordingly (so not anchored at monitor origin).
On Tue Apr 29 13:07:09 2025 +0000, Alexandros Frantzis wrote:
Below are a couple problems I have seen myself (and probably others I am forgetting about). The earlier experimental branch, which also use the "move windows to origin" approach, tried to use some special casing and workarounds for such issues, but the final complexity (and fragility) made the whole effort less enticing compared to some of the other simpler ideas mentioned above.
- Multi-monitor scenarios are problematic with a simple move to (0,0),
especially when combined with fullscreen (since fullscreen is a "state" inferred from window position and size on win32). The (0,0) positioning in the original MR was supposed to be just the first step, since we didn't support multiple monitors then. The experimental branch was tracking which output each surface was on (with enter/leave events), but this turned out to be complex/fragile in terms of syncing etc 2. Applications that are very strong-minded about where they want their windows to be placed, and react with another reposition/resize when we try to position them. A particular problematic case I have seen is in fullscreen or maximized scenarios, with some apps/games insisting that they are sized just a little bit bigger than the target monitor and centering themselves accordingly (so not anchored at monitor origin).
Those do seem like legitimate issues.
However, as it stands, some parts of some windows are simply inaccessible. Has any progress been made on not clipping input?
On Tue Apr 29 13:17:32 2025 +0000, Julian Orth wrote:
Those do seem like legitimate issues. However, as it stands, some parts of some windows are simply inaccessible. Has any progress been made on not clipping input?
I just resurrected an old experimental branch I had, and proposed it to get some feedback about the upstreamability of the approach: https://gitlab.winehq.org/wine/wine/-/merge_requests/7937
-
Alexandros Frantzis (＠afrantzis) -
Julian Orth
-
Julian Orth (＠mahkoh)