Mouse not locking in Wine/Proton programs in fullscreen or windowed #2376
Comments
|
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: ValveSoftware/gamescope#196 (comment) 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: 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 |
|
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: 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:
@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. |
|
@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.
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. Minecraft reproduces this bug very reliably, as in, every time you open the inventory. |
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'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. Oh, also, all of my testing including the tests in in my initial post were also done with |
|
No, the 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. |
Actually, I have an AMD GPU and I use it because my cursor looks like crap.
To that I say,
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
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.
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. |
|
@vars1ty What is mouse warping and how do you enable it? I'd like to try. |
|
@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. |
|
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. ContextThe 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 issueSometimes 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 mechanicsWhen you want to move the camera, the following normally happens:
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 informationI 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 :) |
|
github auto-closes but this needs testing with the mr |
|
Minecraft seems to be working properly now ^-^ |
Are you playing in fullscreen, windowed, or borderless windowed? It's not working for me, borderless window mode, dual monitor setup, Hyprland v0.31.0 |
I play in fullscreen but i believe borderless window also works.
It works for me in dual monitor setup, it only works when you in "controlling character" mode where there will be no cursor render. But if when the cursor render such as when "settings, pause, backpack mode" the mouse will not lock. |
|
@EvilBoi123 that would be the desirable behavior. In “controlling character” mode, I believe the game tries to “lock” the cursor to the center of the screen (that’s what happens on Windows). When I play Genshin on Hyprland, if I move my mouse too far in the direction of my second monitor, the cursor escapes and the in-game camera stops panning. Cursor locking seems to work on x11 GNOME. |
|
I'm having this issue as well, but only when the mouse is visible while being locked (for example, Roblox's first person view and rotating the camera, which keeps the standard mouse visible) |
|
having this issue |
|
I don't know about you guys, but for me the problem is the the refresh rate. If i use 100HZ it won't lock but if i reduce to 60HZ it will lock properly. UPDATE: It seems some programs try to get the refresh rate of the screen but it seems they can't. For example, in ULTRAKILL target framerate was set to '2x of screen refresh rate'. But after i set it to '120' mouse was able to lock in while using 100hz. And the rest of the games/apps without this kind of setting were not able to lock in 100hz |
|
I am not sure if this is the same issue, but I had the problem where opening some games the mouse focus would retreat to the top left corner and not lock on the center of the screen in first/3rd person games, making the game unplayable. A restart of hyprland would fix it every time. This setting seems to work right now: Now if it happens, all I need to do is swap to another workspace and back or Alt+Tab and my mouse is locked into the game correctly. I hope it helps! EDIT - not fixed, I was wrong. |
|
I started having this issue as well 1 week ago after updating from 0.34.0 to 0.35.0. If there's anything I can do to help solve this issue, please let me know and I'll do my best. |
|
More info, this issue only seems to occur when I have a window open on my second monitor (usually discord). So far, this issue hasn't occurred when an empty workspace is open on my second monitor. |
|
its not fixed |
what game you play? |
|
please check #4889 |
|
I experienced an invisible mouse escaping window borders while playing DRG via proton experimental on the center monitor with 3 monitors, it could escape to either side and would change keyboard focus on click if the invisible mouse was outside the game window, but would not change mouse focus. My workaround was to put empty workspaces on the other screens.
Roblox mouse locking was (Roblox blocks wine now) an issue unique to Roblox which happened on any wayland compositor, not just hyprland. Edit: |
|
This issue was the reason I stopped using Hyprland about 6 months ago. It made almost every game unplayable. Now after switching to hyprland-git I can confirm that, at least in Minecraft, the issue is finally no longer present for me. Seriously, thank you for fixing this. Some additional info in case its relevant, Hyprland Packages:
Monitor Configuration:
I cannot currently test the other games I remember being impacted by this issue due to issues with Steam, but I will edit this when I do. |
|
I have this issue when I switch windows out of THE FINALS, and then try to go back to the game. The cursor does not lock so if I turn in the game, my cursor will go to my other screen and the game will lose focus. Mouse lock works perfectly fine before this, its just the second I cycle windows it breaks. Very annoying, re-fullscreening the game does not fix the issue (tried both in-game settings and hyprland keybinds that dispatch fullscreen verb). The mouse is invisible in-game when this occurs. System:
Is there some sort of lock mouse bind that I can set so I can manually lock my mouse as a workaround? I may also give gamescope a try and will edit this message with the results. Edit: gamescope is broken on nvidia |
|
is there any way to fix this at the moment ? i have encounter this not just mouse but also keyboard (more rarely) ? at the moment i just pray to the machine god that my mouse or keyboard don't break after i change focus, workspace. Some time i was able to play fine, sometime it just break right when i start the game. |
|
generally it's mostly problems with the apps themselves, but you can always add 1px of an offset to your monitor whenever gaming and that will prevent the mouse from escaping, I guess. |
|
Fellas, I've been lurking around proton/wine gaming chats for a little while to confirm if anyone can reproduce this issue on other window managers or desktops, and it looks like this issue is indeed an XWayland + Wine issue as this is reproducable on GNOME Wayland, though I have said this doesn't occur on Sway, it is reproducable on other desktops/window managers using wayland. Video of someone experiencing the same bug on GNOME Wayland: possibly related: This is confirmed to be a bug caused by XWayland and Wine in combination now (Though this seems like XWayland's strange mouse properties and such, so it's even more so an XWayland bug) for real and not Hyprland specific. Should I close this issue @vaxerski ? |
|
if it's an xwayland issue, then yea, closing |
|
To be honest I thought the problem was in my configuration, the cursor seemed to lock into the main window, but randomly it goes out when making very quick movements, especially when pressing a large key combination, when sending the position of my main monitor into the stratosphere, none of this happens. This script, as reported above, changes the position of your main monitor, but now automatically. All you have to change is the ID of your monitor. #!/usr/bin/env bash
state="/tmp/togglemonitorlock"
status="false"
# Specify the “ID” of the monitor that is used as the primary monitor, see using hyprctl monitors
id=0
# Monitor ID
monitor=$(hyprctl -j monitors | jq -r ".[] | select (.id == $id) | .name")
# Default position of the monitor
defaultPositionCmd="wlr-randr --json | jq \".[] | select (.name == \\\"${monitor}\\\") | .position\" | awk -F': ' '{print \$2}' | tr -d ' ' | tr -d '\n'"
defaultPosition=$(eval ${defaultPositionCmd})
# Current workspace ID
currentWorkspace=$(hyprctl -j activeworkspace | jq '.id')
# Checking the existence of the status file and reading values from it
if [[ -f ${state} ]]; then
mapfile -t stateValues < ${state}
defaultPosition="${stateValues[0]}"
status="${stateValues[1]}"
fi
# Switching the monitor position and updating the status file
if [[ ${status} == "true" ]]; then
echo ${defaultPosition} > ${state}
wlr-randr --output ${monitor} --pos ${defaultPosition}
echo "false" >> ${state}
else
defaultPosition2=$(eval ${defaultPositionCmd})
# Save the new monitor position if it has been changed by the user
if [[ ${defaultPosition2} == ${defaultPosition} ]]; then
echo ${defaultPosition} > ${state}
else
echo ${defaultPosition2} > ${state}
fi
wlr-randr --output ${monitor} --pos 2000,2000
echo "true" >> ${state}
sleep 0.3
# Restoring workspace
hyprctl dispatch workspace ${currentWorkspace}
fi
I would also like to thank vaxerski for a great window manager! |
|
I'm gonna add more to say that this is an XWayland bug as I was able to reproduce this issue in native linux programs aswell (though on rarer occasions) |
|
@ardishko Thank you for the information about GNOME. In fact, I found this ticket because I am here with the same issue on GNOME 47 Wayland. The issues I have are:
I use Wine 9.22 and tried everything people were talking about trying:
Neither worked. But THIS worked for me:
Edit: Since I use Bottles as my launcher, this is what my correct settings look like. This is probably the necessary fix for every game that doesn't like Wayland's cursors:
(The last button may be hard to understand but it's set to Fullscreen.) |
|
Wine 9.22 has the wayland backend enabled by default now iirc, def check that out if you haven't, It's most likely fixed everything. @Arcitec (I haven't tried it myself yet, just heard it from GamingOnLinux) |
|
@ardishko I was using Wine 9.22 and it still had the mouse jump issue. Not sure if the wayland backend was active or not though... I just used the Kron4ek Wine 9.22 Staging TKG variant in Bottles and it was awful. :) The only solution was Gamescope. And Gamescope solved it even for Wine-GE 8-26. |
|
I have now found out why Gamescope + Wayland + Any game with Vsync crashes. It's an NVIDIA issue, and it's caused by a vsync API that has loooong been buggy. Cubanismo is an NVIDIA developer and comments about it here: If the game uses Direct3D 12 or newer (VKD3D), you can use If it uses Direct3D 11 or older (DXVK) you can't do anything except forcing the game to disable Vsync. For example by launching it without Gamescope, disabling Vsync, and then launching it with Gamescope. The reason why I revisited the topic is that something has broken now. I used to run very nicely without vsync on Wayland. Today I now have permanent screen tearing and judder. Ever since I upgraded from driver Edit: The issues are instantly back when disabling Gamescope: Very tiny mouse cursor icon in the game, and the cursor is warping around so when I click and drag to look around/move the character, the cursor itself really moves in the background so it ends up elsewhere on screen after I stop looking around, which is super tedious, because it means that the next click after you stop looking around can be an accidental click on a UI button. I am trying the latest versions of all relevant components:
Edit: Ugh god damnit. I tried forcing Wine (10.x) to use Xwayland, and set "GrabFullscreen" and "MouseWarpOverride". But it's not working. The cursor is still moving on the real Wayland desktop while the game is supposed to "grab and hold it steady". So the cursor still jumps around the screen. I think I'd rather have disgusting judder and screen tearing than this cursor bug (tiny cursor that keeps warping around). But either is a terrible situation. Edit: In other, stupid news, apparently Wine gained "mouse look and clipped cursor region" support on Wayland in late 2023. But it's not working for me. https://www.phoronix.com/news/Wine-Wayland-Relative-Mouse Edit: Well, after trying Wine 10 and all the settings, I can conclude: Gamescope is STILL the ONLY way to get correct mouse capturing / locking on Wayland.If you don't use Gamescope, you will have a TINY game cursor, and it will be jumping around (not locked to the game at all). This is probably a problem with Wine's implementation of Mouse Capture on Wayland, since Gamescope is able to capture it properly. I also noticed something else: Gamescope is no longer able to vsync at all on Wayland with NVIDIA. Even if I enable vsync in-game (which probably still has the freezing/crashing bug after a few minutes of gameplay on NVIDIA), the game still has tearing and judder. So... I guess the latest NVIDIA driver totally broke vsync on Wayland. |
|
I guess I am going back to X11 to play this game... Edit: Moved back to X11. Disabled Gamescope. Enabled Vsync in game. Now I have tearing-free, smooth gameplay and the cursor locks properly to the game window instead of warping around like an insane rabbit. The only issue I have is that the mouse cursor is small, but that seems intentional because it also happens when I disable "hardware cursor" in WoW (3.3.5a WotLK client), to make the game render the cursor natively inside its own window. So it's probably just that the old game was not made with high DPI screens in mind and has zero code for scaling the cursor. It's interesting that gamescope somehow scaled the hardware cursor to a nice size on 4K resolution, but I chalk that up to gamescope somehow detecting that the cursor was like 32x32 and auto-scaling it intelligently based on DPI in that situation. Wine itself does not seem to have any cursor scaling features (I tried Oh well, a small cursor is the smallest of all the problems I've had. I can live with this. Screw Wayland for now... Final, working setup:
|
and others
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:
Expected Behaviour
Noted Outcome:
Possible related bugs on the issue tracker:
#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)
The text was updated successfully, but these errors were encountered: