Pointer constraints not properly inplemented, windows unable to lock or warp cursor properly

[Ghosthree3]

Hyprland Version

System/Version info

Hyprland, built from branch main at commit 3d9ca6381df1cdbf1731d7e2b39ea3f7574fce1e dirty (crashreporter: fix logging of function data (4632)).
Date: Wed Feb 7 20:50:23 2024
Tag: v0.35.0-7-g3d9ca638

flags: (if any)


System Information:
System name: Linux
Node name: milkbar
Release: 6.7.4-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000


GPU information: 
0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1) (prog-if 00 [VGA controller])
0c:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])


os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo


plugins:

Bug or Regression?

Bug

Description

An active window/client should be able to lock or warp the cursor within its region, this behavior is buggy at best (warps inaccurately, or not at all) and missing at worst (never locks). This has been a long standing issue, though the behavior has changed several times over the last six months. I've been too lazy to report it but a recent commit (cbadf3e3) has made the problem significantly worse because mouse up and down events can now cause a window to lose control of the cursor by briefly selecting a different window (windows only have control of the pointer when focused).

I've created four clips demonstrating the issue, two made under Hyprland, and two made under Sway. Sway seems to support the desired behavior perfectly, and I have confirmed the same behavior under KDE.

These are all recordings of me interacting with Looking Glass, software used to interact with a VM similar to a remote desktop viewer like VNC. The small dot is the local/host/Hyprland cursor position. When Capture Mode is enabled the local cursor should lock in place, when disabled it should be constantly warped to the position of the guest cursor. Looking Glass will not allow the cursor to exit the window if a mouse button is being held down.

These first two clips compare Hyprland to Sway when interacting with the Windows desktop. While the incorrect behavior is slightly annoying (especially when the guest cursor reaches the edge of the window but won't exit because the local cursor hasn't yet, and I have no idea when or where it will because it's usually invisible), it's still usable. I manage to escape the window several times. When not in Capture Mode and holding a mouse button I drag the mouse against the edge of the window, Looking Glass fails to keep the pointer within the bounds of the window so when I click the other mouse button, I manage to click on the terminal, which takes focus, breaking the capture. When in Capture Mode, the local cursor is meant to be locked, but is not under Hyprland, so I simply move it over the terminal and click, disabling Capture Mode.

https://github.com/hyprwm/Hyprland/assets/6110140/43e49b6c-9675-44f2-8aba-d8ad2a21a415

https://github.com/hyprwm/Hyprland/assets/6110140/a99c4c8a-90d0-41e4-a958-199c31786b6a

These next two clips compare Hyprland to Sway when playing FFXIV. Pressing and holding a mouse button "grabs" the screen similar to scrolling on a phone, allowing you to turn the camera. Upon releasing the mouse button the cursor is restored to the position it was at before pressing it. This mouse behavior is common in MMOs like WoW. Obviously, the mouse itself is still moving, so Looking Glass is constantly warping the local cursor back to where the guest/game cursor is being held (or is so under Sway, but not Hyprland). Unlike with the desktop, the behavior here is not just annoying but unusable. When playing the game the cursor constantly leaves the Looking Glass window, usually with a mouse button already being held down. When it does, and the mouse is released, or pressed, capture is broken and the cursor ends up somewhere unexpected like the middle of the Looking Glass window (it should return to where the game cursor was before grabbing the screen), or in another window altogether (which then gets clicked all over).

https://github.com/hyprwm/Hyprland/assets/6110140/7b71622f-b4f0-47fe-9c5c-7d9cf44f96a4

https://github.com/hyprwm/Hyprland/assets/6110140/6a25da93-1012-409d-96e0-5444e874d87a

I believe the protocol responsible for handling all this is pointer-constraints-unstable-v1. lock_pointer is obvious enough, and I believe confine_pointer is used to warp the cursor (by confining the pointer to a specific 1x1 region within the window/client, though this is a guess).

How to reproduce

Unfortunately the only application I know of to well demonstrate this issue is Looking Glass, which requires a functional Windows VM to connect to. If you are able to run Looking Glass, simply run it with the -M flag to enable the local/host cursor dot.

Crash reports, logs, images, videos

No response

[sevy2011]

Can confirm this issue with Enshrouded (Proton). If the cursor is at the edge of the capturing window and you click and move the cursor it moves out of the capture area. With another press or a release you switch focus and loose capture until you focus the capturing window again. Will test it with Avorion (native Linux) and with wine "capture mouse in full screen" / virtual desktop later.

[vaxerski]

a simple test client (not a game or vm) would be helpful

[sevy2011]

Will try and create one at the weekend

[vaxerski]

thanks a bunch. Reply here when it's done, I'll take a look.

[sevy2011]

@vaxerski Okay I can't repro with GLFW under wayland. But also can't get it to run under xwayland as I disabled wayland support and hyprctl is still showing xwayland: 0, by any chance do you know why? My next approche is trying git bisect but haven't done that before so may take a while..

@Ghosthree3 Is looking-glass running under wayland or xwayland? (hyprctl clients to show all running clients, property xwayland)

[Ghosthree3]

@Ghosthree3 Is looking-glass running under wayland or xwayland? (hyprctl clients to show all running clients, property xwayland)

Wayland.

[vaxerski]

patch69.txt try this

[Ghosthree3]

I'm not sure if I patched or installed the patched version incorrectly (patch -p1 < patch69.txt && make all && sudo make install into /usr/local/bin coexisting with a regular install), hyprctl version reported this and I checked src/events/Devices.cpp, the patch was applied.

Hyprland, built from branch main at commit d9757b61bfb7dcfaf3d903092435a1aaff52b7ed dirty (xdg: manually schedule initial configures).
Date: Fri Feb 23 04:33:23 2024
Tag: v0.35.0-78-gd9757b61

but the expected behavior still doesn't seem to be there. That being the local cursor tracking the window/guest cursor 1:1 unless capture is enabled which should lock it in place.

The movement behavior seems the same, though the regression introduced by cbadf3e is now gone (but this is true even without the patch, meaning new builds are at least usable day to day again), even when the cursor is outside of the window during capture mode I can no longer click on other windows to escape and break it. Which is an improvement but still results in severe mouse desync which doesn't happen under both Sway and KDE.

I was a little surprised because to my amateur eyes the patch seemed quite promising, but it seems to have had no effect at all.

I'm not sure if this is helpful or not but I believe these are the relevant lines from the program (Looking Glass) I'm using that has the issue when it comes to how it is locking or warping the cursor. Confine/unconfine: https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L470-L472 https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L484 Lock/unlock: https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L528-L530 https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L540 Warp: https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L606 Also this relative pointer reference seems like it may be relevant but I'm unsure: https://github.com/gnif/LookingGlass/blob/055d5527ef94cdb552252c946ae84be190f3a520/client/displayservers/Wayland/input.c#L345-L347

[vaxerski]

feel free to poke around with the logic in hyprland - I have many things to do and can't focus on this as all in all it's minor compared to other more pressing issues

[Ghosthree3]

No problem. I don't think I have the skills to actually fix this, but hopefully with the information I've provided eventually someone runs into the same problem that can.

[vaxerski]

please check #4889

[rurigk]

Im not sure if the issue i was having is the same as this

The issue i was having is that sometimes when i turned monitor off and on or dmps off on the mouse input was shifted half screen to the right

But now im not facing the issue anymore

[ryleu]

I believe I'm having the same issue as this with Minecraft. Occasionally when left clicking, focus will jump to either another monitor or another window on the same monitor if I'm not in fullscreen. I found a reddit thread that seems relevant: https://www.reddit.com/r/hyprland/comments/1atm4z3/hyprland_gamescope_multimonitor_mouse_focus_issue/

[Ghosthree3]

Closing since all the issues laid out in the OP now seem to be fixed, see https://github.com/hyprwm/Hyprland/pull/4889#issuecomment-2007755554 and the linked comment for more info.