Opened 8 years ago

Closed 7 years ago

#9623 closed defect (outdated)

Mouse capture causes cursor to jump erratically

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


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 8 years ago.
Video of mouse glitch

Download all attachments as: .zip

Change History (7)

by mrprmiller, 8 years ago

Attachment: ScummVM error.avi added

Video of mouse glitch

comment:1 by mrprmiller, 8 years ago

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 by mrprmiller, 8 years ago

Version number is

comment:3 by mrprmiller, 7 years ago

Component: --Unset--GUI

Changed component to GUI to hopefully spark interest into error.

comment:4 by csnover, 7 years ago

Keywords: mouse capture jumping removed

comment:5 by csnover, 7 years ago

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 by rootfather, 7 years ago

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.