The issue is that SDL_GetWindowWMInfo returns a SDL_bool enumeration type
rather than a standard bool. It should be noted that SDL_GetWMInfo used
later in this function returns a int type instead and thus will cast to
bool without warning.
The keyboard repeat event generator is used when building against SDL1.
Previously the repeat events would generate based on the event stream
produced by the keymapper which is not guaranteed to have matching up
and down events in the case the keymaps are changed while a key is
pressed.
Fixes#11417.
Some builds of SDL2 (in my case the vcpkg debug Winx64 build) trigger an annoying and rather pointless assert when calling SDL_GetWindowWMInfo() with a _window parameter of 0 (window && window->magic == &this->window_magic). This commit silences that.
In particular it has been reported that setHelpMenu was introduced in
MacOS X 10.6. So hopefully this change will fix running ScummVM on
MacOS X 10.5 or older.
This might fix bug #11260: MAC OS X: App incomplete when launched on
OS X 10.5.8.
Game controller input is now enabled whenever a compatible device is
connected. The keymapper's keymaps are refreshed when a joystick is added
or removed.
Fixes#10366.
The Virtual Mouse is meant to provide a way to control the mouse cursor
on system without a physical mouse. It provides keymapper actions that
are expected to be bound to game controller axes or buttons.
This was a relatively short-lived port. We have it broken and
disabled on the buildbot since 2016. Also, the last builds
were provided in 2011. Thus, it makes a little sense to continue
to keep the code in the repository, as it gets bitrot.
Backends can still (and do) generate such events. This works around an
issue with the keymapper where the "DOWN" event would be mapped to a
key, but the corresponding "UP" event would be mapped to another one due
to a keymap change. The keyboard repeat generation system would believe
the key to be still pressed and send a continuous stream of repeat
events.
Ideally the keymapper should be fixed to always generate matching event
pairs. However this source of an infinite stream of events still looks
like trouble waiting to happen to me. Hence disabling it by default.