Hyprland
Hyprland copied to clipboard
hyprwm
Mouse not locking in Wine/Proton programs in fullscreen or windowed
It seems like I've found a major bug that could push away a lot of people playing games on Hyprland, It's got to do with mouse locking. Every time I run a game under Wine or Proton, (might not be exclusive to Wine or Proton) after tabbing out for a while and tab back in, the mouse locking is broken. The cursor seems to be still moving. I have tested this under Sway to see if the same behaviour could be observed there and after my testing, I can say that this is exclusively Hyprland behaviour. This doesn't look like It's a Proton or Wine bug, I've tested a lot of games extensively under Sway and Hyprland and It looks like Hyprland has some problems to iron out
Test games were: Deep Rock Galactic (Proton 7.0-6) Overwatch 2 (Latest Wine-GE as of 27-05-2023) (DD//MM//YEAR)
Steps to Reproduce:
Open a game run with Proton or Wine Switch to another workspace for a few minutes, maybe 10 if you want to be sure Switch back to the game and have your mouse lock ruined
Expected Behaviour
For the mouse not to lose it's mouse locking properties after
Noted Outcome:
Mouse locking breaking after switching to a different workspace
Possible related bugs on the issue tracker: https://github.com/hyprwm/Hyprland/issues/1732 (This issue is not the same as my mouse doesn't escape into my other monitor all the time but rather it looks like I am locked between certain regions while in-game which is caused by the mouse getting stuck on the edges of the screen.
It is also worth noting that a similar thing happens on Waydroid while trying to run Roblox on it, though it might be a function on Waydroid not working, since there are issues about that open the Waydroid's Github page too. (Can't test because this stopped working for me, will update if I can test)
Just observed the same behavior whenever the game works normally, the mouse moves in the background but it does not escape the window, It plays normally. Not a problem but it seems like it's related.
I will attach a video when I can get some footage, OBS is acting up a bit.
See here: https://github.com/ValveSoftware/gamescope/issues/196#issuecomment-1531716290 Others users report fullscreen applications don't capture the mouse on Hyprland. I haven't tried a native program.
Also, here is the log. I did quite a few things here so It's quite long. If a cleaner log would be better, let me know and I will log into Hyprland once again to ONLY open steam and launch a game. https://n0paste.tk/mTp0Y54/
It would be cool to know what you mean by broken. Is the cursor lock just gone or what? Also, a "lock" is to a point, a "constraint" is to a region. Let's use the correct terminology to understand this fiasco better.
Constraint is the right word here in that case. Here is a video with footage of what I mean:
https://storage.cloudconvert.com/tasks/486dba08-25bb-4695-a286-ab41b039ccac/2023-05-27%2023-56-06.mp4?AWSAccessKeyId=cloudconvert-production&Expires=1685308861&Signature=jpl6NHtrRBjbzXv%2FpGB0aj1gM0Y%3D&response-content-disposition=inline%3B%20filename%3D%222023-05-27%2023-56-06.mp4%22&response-content-type=video%2Fmp4
Basically, the mouse itself still moves in the background no matter of if it looks like it's constraining me to a certain region like in the video. The camera teleporting around is also another thing to note, I failed to mention it.
Long story short, the mouse does not lock and moves in the background and hits the edge of the screen which ends up looking like it's constraining me to a certain region while in reality, the cursor is just hitting the edge of the screen.
Excuse me If I sound like I don't know what I'm talking about in the video, it's because it's very hard to try to make sense of what's happening on the screen. Perhaps showing it in a screenshare would be best?
jesus christ your voice jumpscared me. Oddity oddity, I might look into the constraints code tomorrow, does sway have the same issue?
Haha sorry about the voice. My mic is a little weird.
About Sway, no it did not. I will be testing it more on Sway to be even more sure but I have been using Sway for almost the whole day and left the game on to test if it would do the same thing, but it did not on multiple occasions.
EDIT: Sway has the cursor moving, but it does not hit the corners of the screen or constrain me in any way.
I play both of the test games (DRG and OW2) - Deep Rock can be played without proton (but no issues when ran with proton either), and Overwatch 2 still runs almost flawlessly for me, aside from terrible performance.
No, DRG doesn't have a native linux version. The "force specific proton version" setting not being on will result in the latest stable proton version being used. (which at the time of writing is 8.0-2) Which is known to work for DRG
As for Overwatch, I have done quite a few tests on Windows and Linux, the performance seems to be relatively the same with a few drops on Wine (tested on Sway and Hyprland seperately) so the performance doesn't seem related to the Hyprland at all.
I have been trying to reproduce this in a native game like TF2 and have not been able to reproduce the issue, albeit because I keep getting kicked because I am idle. More testing is required on that. As per your suggestion (I assume you're raf#0002) I will also test this with only 1 monitor connected soon.
Since this might be relevant, here is my monitor setup data 2K 144hz (Connected via display port) +1080p 60hz (Connected via HDMI) to an AMD Radeon RX 6900XT
Okay, I have tried without my other monitor (the 1080p 60hz one) and the same behavior is present (tested with DRG once again)
And also tried TF2 (native) and left it on for a while and that seems unaffected. I suspect there's a function being called via Proton that's acting weird on Hyprland but not other WMs.
I am experiencing the same issue.
Hardware info: 2 Monitor Setup (Second monitor is disabled during testing) GPU: AMD RX 6700 XT Hyprland config: I can provide my Hyprland config file if needed but it is basically the auto-generated one + vim keybings and i disabled preserve_split (dwindle).
Unlike @ardishco-the-great my cursor lock doesn't work even without window switching. I can confirm sway does not have this issue. Even with setting mousewarp to "force" in wine (with regedit) the issue is still present.
Games tested:
- CSGO (Steam): Linux Native => no issue
- SWAT 4 Gold Edition (GOG): Tested on Wine => issue present
- Fallout New Vegas (GOG): Tested on Wine => issue present
- Bioshock 1 (GOG): Tested on Wine => issue present
- Bioshock 2 (GOG): Tested on Wine => issue present
- Borderlands 2 (Steam): Tested on Proton => issue present
@NotAShelf looking at your config file repo it seems you enable gamemode and disable several animations - perhaps this fixes the cursor capturing. Could you perhaps test if running your games without gamemode enabled produces the bug.
@vaxerski Did you manage to find anything?
Hello guys, and future people i found a workaround for this issue, not comfortable but it do makes gaming less painful.
https://github.com/hyprwm/Hyprland/issues/1732#issuecomment-1582838104
@EvilBoi123 thanks for the tip but it does not work on single display setups, nor does it seem to fix the issue of the mouse getting stuck on the screen border when it is supposed to warp (ex. during a first-person game) on dual display.
Happy that you managed to fix it for your workflow though. Maybe instead of enabling the setting by default you could bind it to a toggle hotkey (P.S. IDK if you can change monitor settings on the fly, but it may be worth looking into).
@EvilBoi123 thanks for the tip but it does not work on single display setups, nor does it seem to fix the issue of the mouse getting stuck on the screen border when it is supposed to warp (ex. during a first-person game) on dual display.
Happy that you managed to fix it for your workflow though. Maybe instead of enabling the setting by default you could bind it to a toggle hotkey (P.S. IDK if you can change monitor settings on the fly, but it may be worth looking into).
Can confirm that you can change monitor settings on the fly. Street Fighter 6 acts weird for me in fights due to it the FPS being locked to 120, I have scripts that change my refresh from 165 to 120 and back again.
hyprctl keyword monitor DP-1,2560x1440@120,0x0,1
hyprctl keyword monitor DP-1,2560x1440@165,0x0,1
On another note, I ran into the same issue of my cursor travelling when it should be "locked" in Minecraft. As an example, when I close my inventory I expect that when I open my inventory back up my cursor should be centred. This doesn't happen, and the cursor appears to be where ever it would be had it been free to move while I was controlling the player's view. This also happens when I open the menu with escape.
This issue appears both when using xwayland to run Minecraft and glfw-wayland, and the cursor is not limited to the game window when it is "locked" and moving. This can result in some very annoying behaviour, when you open your inventory the window can defocus due to your mouse moving. Upon the cursor exiting the window, you then need to move it BACK into the window and toggle your inventory again, and Minecraft will re-grab the cursor for controlling the player's view.
Minecraft reproduces this bug very reliably, as in, every time you open the inventory.
On another note, I ran into the same issue of my cursor travelling when it should be "locked" in Minecraft. As an example, when I close my inventory I expect that when I open my inventory back up my cursor should be centred. This doesn't happen, and the cursor appears to be where ever it would be had it been free to move while I was controlling the player's view. This also happens when I open the menu with escape.
Can't repro.
What if you remove glfw-wayland and use regular glfw? IIRC mc uses glfw no?
Just checked, still results in the same bug. For reference I'm using wayland-nvidia-git, with two monitors. Gamescope doesn't make a difference either way to the problem.
I'm using the nvidia-dkms drivers for g-sync, running arch, all up to date. Using WLR_NO_HARDWARE_CURSORS=1.
I've tested Minecraft on sway and it doesn't have the same problem with the same setup, so it does seem to be specific to hyprland.
Are there any tests I can do on my setup to try and get more information on what might be causing it if you can't reproduce it?
I would like to add that this is not an NVIDIA problem either since the observed behavior is also seen on AMD GPUs. I have an Intel iGPU that I can test with, though I doubt it has anything to do with GPUs.
Another thing I'd like to add is that I have tested Minecraft like @RetoranPetra here and I cannot observe the same behavior. There is something affecting this and the bug doesn't seem to be consistent so it makes it that much harder to reproduce, it seems. I have been experiencing this bug a whole lot less lately though It's still there.
Oh, also, all of my testing including the tests in in my initial post were also done with WLR_NO_HARDWAR_CURSORS=1. I don't really know if it's relevant but maybe it will be useful in tracking down the issue. @ecmatthee Do you also use this envvar on hyprland?
No, the WLR_NO_HARDWARE_CURSORS envvar is unset on my system (running on an AMD GPU).
I do have access to a NVIDIA (which I presume the envvar is mainly for) and an Intel iGPU. I will do some testing on both of them.
Using wine (v8.0), I am still experiencing the bug in all my previous test cases.
I did manage to get Swat 4 working by running it in wine-ge (v8.8) through heroic and Borderlands 2 by running it in proton-ge (I also tested a pirated copy on wine-ge at it seemed to work as well).
I still wouldn't chalk this up as a wine bug as I can't reproduce the issue on Sway, but it does seem that wine-ge & proton-ge fixes the issue for most games.
To add to those I have tested Deep Rock Galactic on Proton Experimental & Proton 7.0-6 and cannot reproduce the issue.
@RetoranPetra I'll check if I can reproduce the issue in minecraft.
No, the WLR_NO_HARDWARE_CURSORS envvar is unset on my system (running on an AMD GPU).
I do have access to a NVIDIA (which I presume the envvar is mainly for) and an Intel iGPU. I will do some testing on both of them.
Actually, I have an AMD GPU and I use it because my cursor looks like crap.
To add to those I have tested Deep Rock Galactic on Proton Experimental & Proton 7.0-6 and cannot reproduce the issue.
To that I say,
the bug doesn't seem to be consistent so it makes it that much harder to reproduce, it seems.
This is very strange because I can't chalk it up to a fucked up wine or proton prefix because I've reset it a lot, can't chalk it up to hardware because It works on other WMs and DEs yet for everyone else different games (or programs that lock your mouse) seem to have the same bug...?
Did you follow my instructions mentioned in the original post? @ecmatthee
Open a game run with Proton or Wine Switch to another workspace for a few minutes, maybe 10 if you want to be sure Switch back to the game and have your mouse lock ruined
If so, then that's pretty strange but It's not surprising given what I mentioned above...
Also, I have found a little bit of a "workaround" for this problem.
- unfullscreen the game
- tile it
- left and right click an bunch of times on your wallpaper or anywhere except a window in the same workspace as the game with this behaviour
- do this for every time this occurs
This works for me but it's obviously not a fix it's simply a way to get around the problem for now.
@RetoranPetra you might find the above helpful until this gets patched.
Experiencing the same issue. Had to enable mouse warp to get it "sorted", although it still escapes the window and goes to the other monitor.
@ardishco-the-great - Essentially doesn't let your mouse leave the focus of the fullscreen application, it's not perfect as you have to focus applications via workspaces on Hyprland, but it works.
For enabling it, in Bottles just go to Virtual Desktop and enable it. For normal wine/proton, https://ubuntuforums.org/showthread.php?t=1603263
Yeah, this one seems to apply as well with Lutris games. It can be mitigated a bit with gamescope, but at times my cam will rocket all the way down/up.
Yeah, this one seems to apply as well with Lutris games. It can be mitigated a bit with gamescope, but at times my cam will rocket all the way down/up.
This happens in Final Fantasy XIV as well, running with XIVLauncher (so not Lutris or gamescope). Camera shoots way up but only sometimes, regardless of mouse movement when I hold to drag the camera.
I did some more testing and found another weird behavior. Sorry if this is long or the diagrams are stupid. I wanted to be as clear as possible.
Context
The game is Final Fantasy XIV, a tab targeted game where you can hold the right mouse button to move the camera around your character. I have a triple monitor set up, with two 1080p monitors at the top and one 32:9 monitor at the bottom, essentially making one big rectangle of pixels. [diagram below]
The issue
Sometimes when holding right click to drag the camera, it will act as if I just did an instant drag down, making the camera face the ground.
Camera mechanics
When you want to move the camera, the following normally happens:
- You hold right click at coordinates A:B
- The cursor disappears
- You move the mouse around
- The camera moves
- You let go of right click
- The cursor re-appears at the A:B coordinates
Weird behavior
When I hold right click in the position C, everything works as expected (besides the issue of the camera being dragged sometimes). I can move the camera as much as I want, and the cursor reappears as expected.
However, doing the same thing at the edge of screen 3 causes the cursor to appear in other monitors. For example, holding right click at position A (labeled in the following diagram) and moving the mouse UP causes the camera to move and the cursor to appear in position B (monitor 1).
Doing the exact same motion with the cursor in position C (for a prolonged period of time) does not yield the same results. I can never see the cursor in other monitors. This leads me to believe this is a result of something weird in the code that handles moving the cursor through monitors.
Ps.: I also found that if I right click the very edge of monitor 3 where it intersects with monitor 1 (so slightly further up from point A), the issue of the camera immediately facing the ground happens around 90% of the time. This is in contrast with doing the same thing at the center of monitor 3, where it happens I would say 5% of the time.
More information
I figured it out, and I need to whip out the diagram again. Sorry. It turns out that there's a particular area in Monitor 3 where clicking does not fire a constraint event in Hyprland's logs, and it triggers the issue immediately. In my case, pictured as a green line in the diagram, it's an imaginary vertical line that extends from where monitors 1 and 2 intersect.
Clicking anywhere in this line while observing the logs means a constraint event is not fired, and the issue is triggered. It also explains why I ran into this issue by clicking near the intersection of 1 and 3, as described in the previous section.
I took the liberty of recording a video that shows the game, the logs and my mouse clicks. You can clearly see mouse clicks not registering a constraint event, which is where I think this issue lies. Unfortunately I can't debug it myself since I'm not familiar with C++, but hopefully this will serve as a good starting point for someone else :)
https://youtu.be/f1gaZIiVdGw
I was away from my PC for a while. Like 3 weeks or something but coming back to this now, I can confirm this behaviour can be observed, though not as common. It's decreased with the recent updates. I don't know which addition or edit did it, but it is worth mentioning.
EDIT: I have read through some of the patch notes, thank for your hard work to everyone who contributed to fixing this issue thus far.
@vaxerski Since this was mentioned as fixed in rel. v0.28.0, perhaps the issue could be closed too?
