MC-126875Mouse input erratic when connected remotely
Remotely controlling the Minecraft client results in erratic mouse movement. (Spinning erratically while looking directly up.) This can easily be duplicated by testing with RDC.
I use Kavoom to control a second account running on a second machine, giving me seamless use of a single mouse and keyboard between two computers. This has worked flawlessly through version 1.12.2. However, now I am now unable to control movement in the snapshot versions on the second machine. The mouse works normally in menus, but not when controlling the character.
Linked Issues
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
LowCreated Issue:
Mouse input erratic when connected remotely
Remotely controlling the Minecraft client results in erratic mouse movement. (Spinning erratically while looking directly up.) This can easily be duplicated by testing with RDC.
I use Kavoom to control a second account running on a second machine, giving me seamless use of a single mouse and keyboard between two computers. This has worked flawlessly through version 1.12.2. However, now I am now unable to control movement in the snapshot versions on the second machine. The mouse works normally in menus, but not when controlling the character.
Environment
Windows 10, Mojang provided java version 1.8.0_25 64 bit.
is duplicated by
is duplicated by
Windows 10, Mojang provided java version 1.8.0_25 64 bit.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
is duplicated by
MC-231807
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
The absolute-position thing was later reported again as MC-126875, and I've submitted a patch to GLFW that should fix it eventually. (That said, I didn't have any issues with RDP on versions of Minecraft using LWJGL 2).
(preemptively, this issue seems like it is semi-invalid, but I'm still going to investigate it as investigated the RDP issue (MC-126875))
Does it not work for any input, or just chat? For instance, can you press W to move forward? Does it work with using / to open chat with a command prefix?
Can you give a sample powershell script using SendKeys, for testing?
Duplicates MC-126875
Thank you for your report!
We're tracking this issue in MC-126875, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Oooh, I might be able to diagnose this a bit, since I've looked at RDP's internals a bit for my (now more or less abandoned) mcrdp project. Unfortunately I don't have a functioning setup at the moment, so I can't reproduce the issue myself.
Anyways, RDP has a Pointer Position Update packet (§2.2.9.1.1.4.2), part of the Server Pointer Update PDU. And, MC got mouse input in 1.12.2 and below by continuously moving the mouse to the center and using offsets from the center to rotate (that's more specifically an LWJGL2 function). That should lead to that PDU being sent to realign the cursor (though, latency might lead to weird things). If that doesn't happen, though, then you'll just continually spin around (MC-81818presents a similar case where the cursor isn't centered again, but without RDP).I'm not sure whether LWJGL3 still uses the move cursor to center system. If it still does, it might be that there's a bug that causes RDP to no longer pick up the movement and center it again. If not, it might be the case that it's detecting movement in a way RDP doesn't understand. I'll investigate what I can.(Update, that wasn't the cause and it does move it back to the center in a way RDP understands; see later comments for my current understanding of it)
Massive comment inbound:
I decided to look over this more thoroughly.
1.12.2
In 1.12.2, the majority of this logic is in MouseHelper, which uses Mouse.setGrabbed. This method is implemented by LWJGL here, but the main logic is in implementation.grabMouse, for windows implemented here. That calls WindowsMouse.grab, which doesn't do anything interesting; however, the relative movement does happen in WindowsMouse.handleMouseMoved.
The logic that actually moves the cursor to the center of the screen is in WindowsDisplay.updateCursor. This handles displaying the cursor and also setting it to a transparent/hidden cursor. It also calls centerCursor, which in turn calls two methods. The second is current_display.setMousePosition (where current_display is this; I'm not sure why it's set up like that), which calls WindowsMouse.setPosition. That just handles some internal stuff. The more important one is nSetCursorPosition, which is a native method implemented in org_lwjgl_opengl_Display.c. That calls windows' SetCursorPos, which presumably does correctly handle RDP things.
1.13
LWJGL 3 doesn't have a general equivalent to Mouse.setGrabbed, other than with nuklear (which is not used by Minecraft). MouseHelper was completely rewritten to manage mouse positions itself (per forge's MCPConfig). The code now looks something like this (these names are my guesses based on previous MCP names for similar code):
These methods are each called once to change the current state (and actually match the general structure of methods declared in Minecraft before). In any case, LWJGL3's GLFW component is a pretty thin wrapper around GLFW itself, so I won't bother to link to it directly. Per glfwSetInputMode's documentation, GLFW_CURSOR_DISABLED is basically the same thing as grabbed cursor, and glfwSetCursorPos behaves differently in that mode. So, the order of setting the position before disabling, but re-enabling before moving the cursor is correct, as part of the fix to
MC-121705.The implementation of glfwSetInputMode is here. Note the call to _glfwPlatformGetCursorPos(window, &window->virtualCursorPosX, &window->virtualCursorPosY). Those fields are declared here and are described as "virtual cursor position when cursor is disabled"; they're used in glfwGetCursorPos and in glfwSetCursorPos when in the disabled mode.
glfwSetInputMode calls the platform-depended _glfwPlatformSetCursorMode; for windows that is this. That in turn calls functions that enable and disable the cursor, which stores the cursor position and centers the cursor. It also registers a raw input device (using windows' RegisterRawInputDevices). Apart from that last step, this more or less matches LWJGL2.
The differences come in the way it handles mouse movement. The handler for WM_MOUSEMOVE is the equivalent to LWJGL2's system... but it doesn't run when in the disabled cursor mode. Instead the raw input handler, WM_INPUT, is used. It looks for changes in cursor position and computes the deltas, and then calls _glfwInputCursorPos with the previous position plus the delta.
However, in no part of the process does it move the cursor back to the center; it just keeps it in the same position. I suspect that's the cause of the issue.ignore that, it does center it, hm.Unfortunately I'm going to need to fix my RDP setup to test further... but this is a start at least.
I got an RDP setup working, and it seems like this is rather a case of RDP doing something weird; a poorly documented MOUSE_VIRTUAL_DESKTOP flag in the raw mouse input is set and it seems glfw doesn't process that (as it's not documented well). I've created GLFW issue #1276 for this and will be testing further later.
OK, I've fixed it on the GLFW end and submitted a pull request. Once that's merged and GLFW releases (and then LWJGL updates their GLFW version and Mojang updates their LWJGL version, which might take a while) this should be fixed ingame. I've also made a modified version JSON for 18w21b that uses the fixed version. To use that, you'd create a new folder in .minecraft/versions named 18w21b-glfwtest, and then save that file as 18w21b-glfwtest.json within that folder. Then you should be able to launch that version in the launcher. If you still experience issues with that, let me know.
@[Mod] Pokechu22 , I've tested your modified GLFW and it does indeed fix the issue with both RDP and KaVoom. Your efforts are stunningly impressive. I appreciate that this will take some time to filter it's way into the official release.
Glad it's helpful!
It looks like the GLFW team has decided that the PR will be for their 3.4 release, which will be a while from now; as such, I've marked this issue as postponed.
When 1.13 itself releases, if the bug itself hasn't been fixed directly, I can make another one of those test version JSONs for it. I'd rather not do it for every snapshot just because that takes a fair bit of time, though.
Confirmed on Windows 7 with Chrome Remote Desktop, TeamViewer and TinyTask. Not affected the same way is the accessibility feature of Windows where you can control the mouse with the numpad, but the speed of camera movement is still inconsistent.
These tests mostly happened a long time ago, but I think I've done a simple test in one of the early 1.13 snapshots and it was unchanged.
Here's a version JSON that uses the fixed GLFW build for 1.13: 1.13_rdpfix.json
(it's the same GLFW dll as before).
@@Edit
Hi Pokechu22,
I managed to launch minecraft with the 1.13_rdpfix, the mouse seems to be a little better as in it does not act as crazy as before however it still does not react accordingly to my cursor move. Is there an up to date fix for this since also the minecraft is in 1.13.2 at this moment?
Kind Regards,
squiku
@squiku: It's definitely not perfect even with the fix, but I don't think it's possible to solve it perfectly (because of latency and such). Most of my testing was with fairly low latency (same network, though wireless); results will vary otherwise. (The basic reason why this happens is that the game receives mouse movements sent your rdp client that were sent before your client centered the mouse again, or something like that at least. But it should avoid the constant high speed issues and if you move the mouse slowly, you'll get consistent results, unlike before. If what I'm saying seems to be wrong, do let me know, since it's been a while.)
I thought that there was some update that made it a bit more complex to use with 1.13.2, but looks like that's not the case (the 1.14 snapshots are a bit more complicated, since they updated LWJGL for those). I should be able to make a 1.13.2 JSON in a bit. In the mean time, can you check whether or not snapshot 19w13b is affected? (I'm pretty sure it is, but I don't have a good setup to test at the moment).
@Pokechu22,
I have downloaded both 19w13b and 19w14a snapshots and none of them seem to have this fixed.
Kind Regards,
squiku
Thanks for checking. I've attached a version JSON for 1.13.2 (1.13.2_rdpfix.json
) which should hopefully work.
Regarding the fix being merged into the main game, it appears that the GLFW team is still working on releasing 3.3, after which the fix will be merged. It looks like they're close, but it might be a while still. After that, the LWJGL team would need to update and then Mojang would need to update LWJGL. So it could take some time. I'll investigate updating my changes to work with the latest version of GLFW when I have more time; I'll need to do that by the time 1.14 releases (as LWJGL was updated including a new GLFW version which is incompatible with my current changes).
@Pokechu22 First sorry to mess with the thread but :
The 1.13. RDP version of you I get pretty fast working, but when I try the same way to use the 1.13.2 version it won`t show that file up in the minecraft version list (In start screen) . Could you detail out on how to get that one working?
The steps I tried to get it working :
Go to %appdata% make a new folder in versions, I called it 1.13.2-RDP, inside that folder I created a file called 1.1302.RDP.json .
But for some reason I get it pretty fast setup for 1.13.1/0 but for 1.13.2 its just a no go?
Hope u don`t hate on me for that?
Confirmed for classic.minecraft.net.
As of 1.14.3, this issue seems to have been resolved. I can no longer reproduce this issue.
That seems odd given that the pull request I made before hasn't been merged yet (I think), but it's quite possible that it was still fixed another way. I think GLFW did rework input a fair bit, so it's entirely plausible that it was fixed with something else. If I recall correctly, 1.14.4 (or its prereleases) introduces a "raw input" option; can you check whether it also is fixed when using that?
I have been having the same issue when I got on my second computer I can basically look only up or down the anytime I move my mouse I spin really fast and I am playing on 1.14.3 is there anyway to fix it
I can confirm the erratic mouse input
In 1.12.2 and below when I connect to my pc remotely I'm able to mouse the around if I put the sensitively right down
but in 1.13.0+ the mouse moves around at hyper hyper speed and windows mouse keys no longer work aswell
With "raw input" off, I get pretty much the old behaviour, with "raw input" on it's much worse.
I also have tried to set raw input to off and even tried it out with touchscreen mode on and off.
it get's a little bit better with raw input set to off, but still not playable, as nearly all mouse movement will still be interpretet as up or downwards movement with a spin in it. In the lower versions, like already mentioned (1.12.2 and below) everything works normal.
Additionally to that, in the lower versions, the mouse will be catched, which is not happening on the later versions.
With the 1.14.4 release, the issue has returned. Raw Input "Off" does solve the problem" for me.
Can someone please tell me what I'm doing wrong? I've gone into the versions folder, made a new folder called 1.13.2_rdpfix and then inside that put the 1.13.2_rdpfix.json file in there, then in the Minecraft launcher added it as a new installation, and then when I go to start it, it downloads all the files then I get "Exited with error code -1" and no more info.
I tried again with 18w21b-glfwtest and got this error
not sure why snapshot exits with crash info and exit code 1 while the 1.13.2 one displays no crash info and exits with -1, but regardless neither work
Windows 10 Pro Version 1909 Build 18363.476 over RDP with Intel HD Graphics, graphics acceleration isn't the issue as that's working just fine and regular 1.13.2 and 1.12.2 launch just fine, just with the mouse issue.
Downgrading to Windows 10 Version 1803 Build 17314.112 fixed the mouse issue in 1.12.2, it appears that something changed between this version and the latest build (1909) that broke mouse support despite it working previously
That's not even the same game.
I can confirm was Lukas Lüdke said in https://bugs.mojang.com/browse/MC-126875?focusedCommentId=568050&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-568050 using 1.15.2 here and TeamViewer.
Can confirm this issue on 1.16.5 on Linux (x64) using NoMachine.
Can confirm this issue on MC 1.16.5 on Debian GNU/Linux (amd64) using remmina RDP (client) and Windows 10 (server).
Years later and still no fix to this issue that several other games have fixed?
I'm really beginning to wonder if Mojang has any say in what they do or if M$ is just pulling all the strings at this point.
Any update on this in 2022? Can confirm this issue is still here on MC 1.18.1 using windows RDP.
Please fix this bug. It's still in the game, 1.18.2 and latest versions. This bug is very old and still not fixed. I'm very disappointed.
This is not a bug with minecraft, it is an issue with remote desktop clients not locking the cursor. Some remote desktop software like chrome remote desktop has an option for locking the cursor which fixes this issue
Interesting theory! But sadly it doesn't work. I just connected via AnyDesk, locked the local input and it still kept spinning around way too much and randomly looking up and down, like before. I think the more likely explanation is that when you move the cursor a bit to the right, it properly moves the in-game cursor to the right, but then resets the mouse. When you then move a bit more to the right, it moves the cursor the previous distance plus the new distance to the right, resulting in a much bigger motion and then Minecraft resets the cursor again. Summing up all previous vectors can lead to strange results like moving the cursor up and actually having the view move down, just because you moved more down than up on average so far.
This could be blamed on the remote control software, but it happens even with relative mouse movements like with xdotool.
Edit: I just tried "direct mouse mode" and it seems to confirm this. When I hold my finger very close to the crosshair, I can kind of control the game like with a virtual motion stick, just an extremely sensitive one and only while moving the finger.
BTW, if anyone intends to use remote-control to play Minecraft Java edition on the phone, I can recommend "PojavLauncher" instead, it actually runs the game on the phone instead of such workarounds. Of course that requires a fast phone, but mine can easily reach 60FPS on minimum graphics settings. The controls are even good enough that I used it once to deliver items to a faraway location, but it's not as good as playing on a computer, of course.
I am also running into this issue. My team was hoping to use Minecraft as a teambuilding exercise, but this issue is preventing some members from being able to participate fully.
Replicated on Windows 10 21H2, Minecraft 1.19.3
The menus all seem to be fine, but game play is unplayable.
Happy to help provide better logs or anything else that will help resolve the issue
Still occurs on 1.20.4. I'm very disappointed that a bug this old and problem-causing still occurs.
GLFW merged the change to fix RDP at https://github.com/glfw/glfw/pull/2431 (I'm pretty sure it's included in the GLFW 3.4 release). LWJGL hasn't yet updated to the new GLFW version as far as I can tell though, so Mojang can't update to a new LWJGL version to fix it just yet.
Still occurs on 1.21.
Luckily LWJGL updated GLFW in version 3.3.4, hopefully Mojang will update LWJGL to version 3.3.4 to fix this issue as soon as possible.
On the latest 1.21.4, the problem still exists.
Mojang is still using LWJGL 3.3.3 as of 1.21.4, so that makes sense.