Opened 2 years ago

Closed 15 months ago

#9623 closed defect (outdated)

Mouse capture causes cursor to jump erratically

Reported by: mrprmiller Owned by: rootfather
Priority: normal Component: GUI
Keywords: Cc:


When I press CTRL+M to lock the mouse to the ScummVM window, whether in the engine or in a game, the mouse cursor no longer moves smoothly. It jumps to various locations all over the ScummVM window, making the engine/game unable to be navigated until I unlock the mouse capture with CTRL+M again, at which point mouse movement resumes to normal (but of course allows the cursor to be moved out of the window borders).

This is on a Windows 10 PC laptop, with both the touch-pad and an external USB mouse.

I have a small video capture showing the problem.

Attachments (1)

ScummVM error.avi (597.0 KB) - added by mrprmiller 2 years ago.
Video of mouse glitch

Download all attachments as: .zip

Change History (7)

Changed 2 years ago by mrprmiller

Attachment: ScummVM error.avi added

Video of mouse glitch

comment:1 Changed 2 years ago by mrprmiller

First part of video shows mouse unlocked, acting normally. Second part shows how mouse behaves after pressing CTRL+M. Third part unlocks mouse capture again, showing it goes back to normal.

comment:2 Changed 2 years ago by mrprmiller

Version number is

comment:3 Changed 2 years ago by mrprmiller

Component: --Unset--GUI

Changed component to GUI to hopefully spark interest into error.

comment:4 Changed 16 months ago by csnover

Keywords: mouse capture jumping removed

comment:5 Changed 16 months ago by csnover

Recently there have been changes to the backend code that handles code related to input grab and mouse input. Could you please try again with a daily build using SDL2 and let me know if the problem still exists?

Also, please verify that you are not running ScummVM inside a virtual machine with mouse integration turned on, since mouse integration does not work correctly with input grabbing in exactly the way you are describing here. Thanks!

comment:6 Changed 15 months ago by rootfather

Owner: set to rootfather
Resolution: outdated
Status: newclosed

I could indeed verify this using the SDL1 builds provided by the buildbot. I couldn't reproduce it on the current SDL2 builds though. SDL1 is quite outdated and incompatibility with current Windows systems is constantly growing - this is why we transitioned to SDL2.

Note: See TracTickets for help on using tickets.