Oct. 6, 2023
7:59 a.m.
On Fri Oct 6 11:12:52 2023 +0000, Alexandros Frantzis wrote: > > 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/41ab207c71cfaa82ef95c83b291654aba023a45c/server/queue.c#L451) > 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/41ab207c71cfaa82ef95c83b291654aba023a45c/server/queue.c#L451), > 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. No idea what else it would break but what about always using a maximal virtual desktop size on Wayland and ignoring the monitor coverage? That would be a change limited to `wayland_resize_desktop`, and in theory the rest should just work as if we had very very large monitors? Otherwise I think this is some consideration that could be left for later, I don't think it's a huge issue if windows that are moved out of the virtual screen cannot be interacted with, at least not at this point. It's not a very common scenario, or is it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47869