Rewritten pointer constraints #4889
Conversation
|
this helps with part of #4650, which affects me, that is - hyprland switching focus to another window on click of a "phantom pointer". tested on Arch with looking glass mouse desync is still an issue. it seems as if hyprland remembers the pointer position at the time of "handing over" control of the pointer over to looking glass, and sets pointer back there when looking glass "releases" control of the pointer. expected behavior would be that both pointers are in sync, but that might be too application-specific. overall, this is an improvement also, now, with input capture enabled in looking glass, keyboard input is also fully passed to the window, instead of hyprland reacting to keybinds from the config first, which seems to be a "more correct", but still, a change in behavior. for example, i used to be able to switch between workspaces without toggling input capture in looking glass |
that is true, but it should warp the cursor to the set region in the meantime... 🤔 |
|
how about now? |
|
i do not notice any change, other than 6d82f07 leading to crashes, which seems to have been fixed by d2dc4b5. just in case, attaching a crash report |
|
no, those crashes are still on this MR, they've been fixed in main. Let me rebase |
vaxerski
force-pushed
the
rewrite-constraints
branch
from
d2dc4b5 to
cb13dcf
Compare
|
I did a little bit of testing now, but will have to look closer tomorrow. Regarding #3672: in FF the camera flick happened only once so far (might've been related to a steam notification I got at that moment?). It rarely happened on wallpaper change as well, but I didn't spend enough time playing to tell if that has changed. This change also changes the behavior of #4497. It now doesn't happen on every wallpaper change but still happens sometimes. I think unlike before it now snaps to the same position each time. |
|
both of you check now |
|
committed |
|
This mostly fixes #4650, at least in terms of the cursor remaining captured when being captured. The local cursor now appears to track the application cursor accurately, and is aggressively warped to maintain that if the application is trying to 'hold' it, like in some video games (like seen in the 4th video of that issue). There is one issue though, the true location of the cursor seems to be locked somewhere near where you entered the window (how far away from the border is somewhat random, I assume however far you managed to move the cursor before the application window, or Hyprland, I'm not sure, 'noticed' you were inside). When the application attempts to lock the cursor it can be seen to warp there instead of being frozen where it was when the lock occurred as it should (as shown in the sway demos in the mentioned issue). It also tries to move but is warped repeatedly back the same way it does when NOT locked but being held still by a game like previously mentioned, while it shouldn't be able to move at all. This wouldn't be the end of the world but for the next part. Despite the local cursor appearing to be in sync with the application while within the application, when exiting the window the cursor is warped to that same position along the edge where you entered, causing you to have to exit twice. This is especially noticeable if you're attempting to exit the window from the opposite side that you entered from. For example, if I enter the window with the cursor from the left, then want to exit to the right, as I reach the right side edge the local cursor will warp all the way back to the left and have to be dragged all the way across the window for a second time (but this time out of sync with the application cursor) to actually exit. If exiting from the same side that I entered from the same thing occurs but the distance is significantly less. If I had to guess, the issue is that when the window is not trying to warp the mouse anymore the cursor is reset to its entry position rather than to the last position it was moved/warped to by the window. It probably shouldn't have any 'memory' of that at all, it should just continue to be moved until it isn't. See video below for a demo, reminder that the dot is the local/Hyprland cursor position. hyprland_lg_mouse_demo_4889.mp4This is still an overall improvement in that while leaving the window is a little strange now, at least you don't accidentally leave when you don't want to. EDIT: There are scenarios that can cause the mouse to infinitely warp back to its entry position when trying to exit making leaving the window with the mouse impossible, a keyboard shortcut to move window or change workspace is required. |
|
try now @Ghosthree3 |
Behavior seems identical to the above post. |
|
dam alright but since it solves so many issues I'll merge it, seems like it's in a good state Thanks all, further issues shall be dealt with in the futrue |
Might need a bit more info; I've been playing fullscreen games with this commit and I'm not getting displaced mouse issues. How many displays, which game(s) etc? |
|
@zakk4223 single monitor at 0x0. Various games, Balatro is what I've been using as a repro because it's consistent and fast to start up, but also happens on League randomly, and those are the only two I've tried until now. I just tried a couple of others and they didn't produce the bug. |
|
Sorry if this is dumb but, I've updated |
|
cleanbuild if on yay, nuke the cache if on paru |
|
gotcha, did everything and it looks like i'm still having the same issues :/ |
|
You could have multiple hyprland installs on your system, try |
|
nope, i only have one binary on my system |
Also happens in-game in Dota 2 (initial client UI is fine, starting a game/arcade game results in offset cursor). |
Just FYI, I can no longer reproduce as of 6633028 so I would guess something between d72ea5f and now has resolved this. |
Most likely 024d4dd |
|
This (#4889 (comment)) issue is now fixed and Hyprland's behavior is almost identical to Sway's. The only difference I can see is that during capture/lock mode the cursor technically isn't locked/frozen (which it should be), but is repeatedly warped back to the position it should be locked at, so to the user it is effectively the same. I will close #4650 as all the issues I raised there now seem to be resolved. |
|
#3672 is not fixed yet. In FFXIV in particular there used to be a "mouse spazzes out upon focusing the window" bug, but now there is also a bug where the camera is just randomly pointed to a random direction, especially on mouseclick (?). Is there something you'd need help with in order to diagnose this? For context, I'm spamming right click to take control of the camera and every so often when doing so the camera is pointed down and to one side, seemingly randomly. 2024-04-06_12-13-31.mp4 |
* rewritten constraints * send pointer enter on activate if not pointer focus * minor cleanup * simulate movement on commit * don't ignore oneshot prop * various fixes * dont send motion on confined * update pos hint on region change
This PR rewrites constraints from the ground-up, cleans the code, yadda yadda yadda.
Possibly fixes, so CC for testing: (if your issue is in here, please report with a comment either "my issue #XYZ was fixed" or "my issue #XYZ was not fixed")
#4867 #4650 #4465 #4348 #3669 #2376 #1732 #3672 #3270
cc @fufexan for review