Current Behaviour
After switching from the mouse back to the controller while the inventory is open, the virtual cursor snaps to the center of the screen and jitters rapidly while the stick is held. The "Controller disabled" toast (the controller conflicting with keyboard and mouse) appears, and appears again every time the stick is released and moved again. B no longer closes the screen. Only E or Escape gets out, and leaving the screen clears the problem.
Expected Behaviour
Switching from the mouse back to the controller in the inventory should bring the virtual mouse back at the position the real mouse was at, with no jitter, no "Controller disabled" toast, and B still closing the screen.
Screenshots
No response
Reproduction Steps
- Open the inventory with the controller (Y). The virtual mouse appears and works.
- Move the real mouse a little, so input switches to keyboard/mouse.
- Without closing the inventory, move the controller stick again.
- The virtual cursor jumps to the center and jitters, the "Controller disabled" toast appears, and B no longer closes the inventory.
Logs
[23:22:16] [Render thread/WARN]: Controlify detected current controller to be constantly giving input and has been disabled.
[23:22:52] [Render thread/WARN]: Controlify detected current controller to be constantly giving input and has been disabled.
Mod Version
3.5.1+mc26.3 (Fabric)
Controller
Flydigi Apex Xbox layout, Xinput device
Bluetooth
Operating System
Windows
ARM
Additional Information
Likely cause:
On 26.3, CursorUtils.setPosition uses SDL_WarpMouseInWindow. Outside relative mouse mode, SDL reports every warp as a normal mouse motion event (it never drops it as a no-op, because the warp clears SDL's last known position). SDLEventHandlerMixin treats that event as the player using the mouse and switches to KEYBOARD_MOUSE. That disables the virtual mouse, which warps again, while the held stick switches back to controller, which re-enables the virtual mouse and warps again. The input mode flips every tick until consecutiveInputSwitches passes 100 and the faulty input detection disables the controller. GUI_BACK is lost because tickActiveController returns early on every mode change.
The snap to center is a separate small issue: when switching to controller, setInputMode calls hideMouse(true, true), which moves Minecraft's cursor to (-50, -50) before the virtual mouse is enabled. enableVirtualMouse then treats -50 as "no position" and centers the virtual mouse.
Possible direction: ignore mouse motion events that are the echo of Controlify's own cursor warp (for example, remember the warp target and skip motion events that land on it), and don't park the cursor at (-50, -50) when the screen is about to use the virtual mouse.
Just to make sure...
Current Behaviour
After switching from the mouse back to the controller while the inventory is open, the virtual cursor snaps to the center of the screen and jitters rapidly while the stick is held. The "Controller disabled" toast (the controller conflicting with keyboard and mouse) appears, and appears again every time the stick is released and moved again. B no longer closes the screen. Only E or Escape gets out, and leaving the screen clears the problem.
Expected Behaviour
Switching from the mouse back to the controller in the inventory should bring the virtual mouse back at the position the real mouse was at, with no jitter, no "Controller disabled" toast, and B still closing the screen.
Screenshots
No response
Reproduction Steps
Logs
Mod Version
3.5.1+mc26.3 (Fabric)
Controller
Flydigi Apex Xbox layout, Xinput device
Bluetooth
Operating System
Windows
ARM
Additional Information
Likely cause:
On 26.3, CursorUtils.setPosition uses SDL_WarpMouseInWindow. Outside relative mouse mode, SDL reports every warp as a normal mouse motion event (it never drops it as a no-op, because the warp clears SDL's last known position). SDLEventHandlerMixin treats that event as the player using the mouse and switches to KEYBOARD_MOUSE. That disables the virtual mouse, which warps again, while the held stick switches back to controller, which re-enables the virtual mouse and warps again. The input mode flips every tick until consecutiveInputSwitches passes 100 and the faulty input detection disables the controller. GUI_BACK is lost because tickActiveController returns early on every mode change.
The snap to center is a separate small issue: when switching to controller, setInputMode calls hideMouse(true, true), which moves Minecraft's cursor to (-50, -50) before the virtual mouse is enabled. enableVirtualMouse then treats -50 as "no position" and centers the virtual mouse.
Possible direction: ignore mouse motion events that are the echo of Controlify's own cursor warp (for example, remember the warp target and skip motion events that land on it), and don't park the cursor at (-50, -50) when the screen is about to use the virtual mouse.
Just to make sure...