[PATCH] winex11.drv: Don't confine the pointer to any window when just checking for active grab.
Fixes a regression introduced by 74efb3e872aebf57a42d62b52e149ae26f320c9a, which caused some random pointer warping on a setup with multiple "workspaces" when switching between them and a full screen game that warped the mouse. Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- As I understand, that commit was supposed to just check for a pointer grab, and temporarily "lock it" if it was free, while the pointer is warped via XWarpPointer. There's no need to confine it to root_window in this case, which causes issues with multiple workspaces apparently. It's not easy to reproduce reliably, but an example game to reproduce this with is SpellForce. Place the game in a Virtual Desktop that covers the entire screen on a different workspace (say, to the right of the current one). When entering a map, move the mouse in game to the left so it moves the map view. While this happens, quickly switch to the left workspace (with shortcuts), then the pointer will at seemingly random times warp to the right edge of the screen while you are in the new workspace (because the game's workspace is to the right). This patch, however, fixes that issue and many others that are hard to reproduce reliably, while switching workspaces from a fullscreen game. dlls/winex11.drv/mouse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c index 290732f..7f0edd9 100644 --- a/dlls/winex11.drv/mouse.c +++ b/dlls/winex11.drv/mouse.c @@ -1478,7 +1478,7 @@ BOOL CDECL X11DRV_SetCursorPos( INT x, INT y ) if (!clipping_cursor && XGrabPointer( data->display, root_window, False, PointerMotionMask | ButtonPressMask | ButtonReleaseMask, - GrabModeAsync, GrabModeAsync, root_window, None, CurrentTime ) != GrabSuccess) + GrabModeAsync, GrabModeAsync, None, None, CurrentTime ) != GrabSuccess) { WARN( "refusing to warp pointer to %u, %u without exclusive grab\n", pos.x, pos.y ); return FALSE; -- 2.21.0
On 1/15/20 1:21 PM, Gabriel Ivăncescu wrote:
Fixes a regression introduced by 74efb3e872aebf57a42d62b52e149ae26f320c9a, which caused some random pointer warping on a setup with multiple "workspaces" when switching between them and a full screen game that warped the mouse.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> ---
As I understand, that commit was supposed to just check for a pointer grab, and temporarily "lock it" if it was free, while the pointer is warped via XWarpPointer. There's no need to confine it to root_window in this case, which causes issues with multiple workspaces apparently.
It's not easy to reproduce reliably, but an example game to reproduce this with is SpellForce. Place the game in a Virtual Desktop that covers the entire screen on a different workspace (say, to the right of the current one). When entering a map, move the mouse in game to the left so it moves the map view. While this happens, quickly switch to the left workspace (with shortcuts), then the pointer will at seemingly random times warp to the right edge of the screen while you are in the new workspace (because the game's workspace is to the right).
This patch, however, fixes that issue and many others that are hard to reproduce reliably, while switching workspaces from a fullscreen game.
dlls/winex11.drv/mouse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c index 290732f..7f0edd9 100644 --- a/dlls/winex11.drv/mouse.c +++ b/dlls/winex11.drv/mouse.c @@ -1478,7 +1478,7 @@ BOOL CDECL X11DRV_SetCursorPos( INT x, INT y ) if (!clipping_cursor && XGrabPointer( data->display, root_window, False, PointerMotionMask | ButtonPressMask | ButtonReleaseMask, - GrabModeAsync, GrabModeAsync, root_window, None, CurrentTime ) != GrabSuccess) + GrabModeAsync, GrabModeAsync, None, None, CurrentTime ) != GrabSuccess) { WARN( "refusing to warp pointer to %u, %u without exclusive grab\n", pos.x, pos.y ); return FALSE;
This looks good to me in any case but there's a bug report [1] that says the original commit introduced some sluggishness. I wasn't able to reproduce it, but that may be because I use only one workspace? Does this fix the sluggishness as well? [1] https://bugs.winehq.org/show_bug.cgi?id=47771 -- Rémi Bernon <rbernon(a)codeweavers.com>
On 15/01/2020 15:51, Rémi Bernon wrote:
On 1/15/20 1:21 PM, Gabriel Ivăncescu wrote:
Fixes a regression introduced by 74efb3e872aebf57a42d62b52e149ae26f320c9a, which caused some random pointer warping on a setup with multiple "workspaces" when switching between them and a full screen game that warped the mouse.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> ---
As I understand, that commit was supposed to just check for a pointer grab, and temporarily "lock it" if it was free, while the pointer is warped via XWarpPointer. There's no need to confine it to root_window in this case, which causes issues with multiple workspaces apparently.
It's not easy to reproduce reliably, but an example game to reproduce this with is SpellForce. Place the game in a Virtual Desktop that covers the entire screen on a different workspace (say, to the right of the current one). When entering a map, move the mouse in game to the left so it moves the map view. While this happens, quickly switch to the left workspace (with shortcuts), then the pointer will at seemingly random times warp to the right edge of the screen while you are in the new workspace (because the game's workspace is to the right).
This patch, however, fixes that issue and many others that are hard to reproduce reliably, while switching workspaces from a fullscreen game.
dlls/winex11.drv/mouse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c index 290732f..7f0edd9 100644 --- a/dlls/winex11.drv/mouse.c +++ b/dlls/winex11.drv/mouse.c @@ -1478,7 +1478,7 @@ BOOL CDECL X11DRV_SetCursorPos( INT x, INT y ) if (!clipping_cursor && XGrabPointer( data->display, root_window, False, PointerMotionMask | ButtonPressMask | ButtonReleaseMask, - GrabModeAsync, GrabModeAsync, root_window, None, CurrentTime ) != GrabSuccess) + GrabModeAsync, GrabModeAsync, None, None, CurrentTime ) != GrabSuccess) { WARN( "refusing to warp pointer to %u, %u without exclusive grab\n", pos.x, pos.y ); return FALSE;
This looks good to me in any case but there's a bug report [1] that says the original commit introduced some sluggishness.
I wasn't able to reproduce it, but that may be because I use only one workspace? Does this fix the sluggishness as well?
I haven't experienced any sluggishness yet, but I haven't tested any of the games in the bug report. That said, it was very annoying to bisect also because it seems kind of random when it triggers, for some reason (maybe it depends on what the game does), so maybe I just didn't run into this problem yet. Hopefully someone from the bug report can test it and report.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- Even though it doesn't fix https://bugs.winehq.org/show_bug.cgi?id=47771 the intent was indeed not to confine the pointer.
participants (2)
-
Gabriel Ivăncescu -
Rémi Bernon