During normal runtime of my game, the mouse cursor is often captured, as it should be, but every time I set a breakpoint in my IDE then hit it, my IDE gets focus, the game is frozen (as it should be), but my cursor is still captured by the game, and I cannot get it back unless I force-terminate the debugging session with a hotkey. I couldn’t really find any information about this online, and it is something that gets quite annoying after a while. Any help is greatly appreciated!
I think i have seen this too. Can Alt+tab get you out of the window? Maybe try to minimize the window, or make the window slightly smaller so there is a margin that the mouse won’t be over the captured window. I think i have a small window for the game then i can Alt+ tab out but my mouse will only show when it’s not over the game window. Then i probably minimize it.
Alternatively, If you want to you could change capture mode before breaking. Just use breakpoint keyword. And before it’s executed chang mode.
But this wouldn’t help if there is a runtime error. So i guess try shrinking the game window size.
I’m hitting the same. For me (Fedora 41 KDE) game window, editor and IDE have no mouse, while other windows and the panel etc. do have it.
Alt+Tab doesn’t help me.
Did you find a solution? If not I might open an issue since I haven’t seen one except for the very old #2232 and it is really annoying.
Unfortunately I did not find a solution, and for some reason everyone shrugged it off as “not an problem” or “just keep your mouse cursor unlocked” which is honestly a really annoying mentality. I’m going to say it’s a bug with certain Desktops, but I’m not skilled enough to fix it. For the time being, I simply just keep the mouse unlocked, but it’s NOT a solution, as in some 3D scenarios, I NEED to be able to move the camera around before hitting a specific breakpoint. I’m currently on PopOS and the issue is still present with X11 and Gnome.
I tried some more things and running Rider in the experimental Wayland mode described here solves the issue for me.
But for once that is not smooth sailing with several other issues and obviously won’t help people on X11 only distros.
I just tried on x11 and gnome with ubuntu24 with Godot 4.3, the issue does not happen anymore.
But my previous solution when i experienced the problem was to run the game windowed, smaller then your display, or on a second display, so you can move your mouse out of the capture zone of the window.
I only have a single monitor setup right now, and I’m still running X11 on Manjaro on my main PC and there’s still no way to move the mouse “away” even when it’s captured. I also tried switching workspaces, also did not work, and same on my laptop with PopOS, unfortunately it’s broken there too.
I think for the time being I’ll just deal with the issue, but hope that it’ll get fixed soon!
(Or maybe wayland gets more usable before it’s fixed )
what if you tried this?
when you evoke the game instance to run, set the display driver to wayland for the game. if the issue is the xWayland crossover. just make it wayland if your distro is also wayland?
Oh okay, i would not use godot in pure wayland it does not work well. Xwayland is okay but has new issues in gnome 46 when saving resources and soft locks. I now just do x11 just for stability.
According to the EngineDebugger source code and the RemoteDebug functionality, it will disable mouse capture before acting on a breakpoint or error.
So at least godot is trying.
Idk then if this is a OS/Desktop issue or some sort of race condition between godot actions and the OS.
I would double check everything is upto date with your current software.
I did find this which may help but i haven’t tested it or know if XF86Ungrab is available on your setup. You may be able to setup a keyboard shortcut.
)