I'm also not sure to understand what you mean by Windows virtual space being clipped compared to Wayland input space, do you mean when ClipCursor is used?
In this case, I am referring to the cursor clip which is effective when we don't have a set ClipCursor. That effective clip is set to the extents of the desktop window, which matches the virtual screen rectangle. For a more concrete example of the issue, consider:
1. A single monitor 100x100 at (0,0), so desktop window and vscreen is (0,0)-(100,100) (right-open interval). 2. A 50x50 window at (-25,0) in Windows virtual screen, so the left half part is out of the screen from Windows' perspective. 3. The corresponding Wayland surface is fully visible to user, let's say at (0,0)-(50,50) in the Wayland compositor space. 4. The user moves the mouse to Wayland (0,0), i.e., the top left of the surface, and the driver sends a input mouse event with screen coordinates (-25, 0). 5. During hardware event processing in the server, the (-25, 0) coordinate is [clipped](https://gitlab.winehq.org/wine/wine/-/blob/41ab207c71cfaa82ef95c83b291654aba...) to the effective (desktop window) clip, so it becomes (0,0), and the cursor position is updated accordingly. 6. The result is a confused user, which can't meaningfully interact with the left part of the surface, despite it being fully visible to them.
Given the lack of Wayland absolute positioning (see other comment about why I don't think this is coming any time soon), here is a more detailed summary of alternatives to try to mitigate the problem:
1. Move the window to (0,0) (i.e., the current proposal), to maximize the region of the window that is accessible to input events. As mentioned, I have had good practical results with this approach, but it is imperfect because: a. It doesn't help if the window is larger than the vscreen, in which case the right and bottom parts are still effectively inaccessible b. As you mention, some apps many not be happy with our forceful moves.
2. As proposed in the MR description, introduce a mechanism to circumvent the clipping for mouse input messages sent by the driver, e.g., `__wine_send_input(..., WINE_INPUT_IGNORE_CLIP)`. As a quick experiment I commented out the server [clipping](https://gitlab.winehq.org/wine/wine/-/blob/41ab207c71cfaa82ef95c83b291654aba...), and the results were positive. However, I don't know if ignoring the clip in this way for Wayland input events would invalidate some very core assumptions, and if it would confuse applications. I imagine some apps will also perform their own internal clipping.
Of course, I would be more than happy to hear any other alternatives!
As things stand in the Wayland world, I don't think we can be perfect here. We are solidly in best-effort territory, but, even so, I do think we can cater to the majority of use cases.