If you continually poll for events it's possible that new events can come in while you're still processing the last one, delaying rendering. This is more likely with high update rate sensors.
When possible use native os functions to make a blocking call waiting for
an incoming event. Previous behavior was to continuously poll the event
queue with a small delay between each poll.
The blocking call uses a new optional video driver event,
WaitEventTimeout, if available. It is called only if an window
already shown is available. If present the window is designated
using the variable wakeup_window to receive a wakeup event if
needed.
The WaitEventTimeout function accept a timeout parameter. If
positive the call will wait for an event or return if the timeout
expired without any event. If the timeout is zero it will
implement a polling behavior. If the timeout is negative the
function will block indefinetely waiting for an event.
To let the main thread sees events sent form a different thread
a "wake-up" signal is sent to the main thread if the main thread
is in a blocking state. The wake-up event is sent to the designated
wakeup_window if present.
The wake-up event is sent only if the PushEvent call is coming
from a different thread. Before sending the wake-up event
the ID of the thread making the blocking call is saved using the
variable blocking_thread_id and it is compared to the current
thread's id to decide if the wake-up event should be sent.
Two new optional video device methods are introduced:
WaitEventTimeout
SendWakeupEvent
in addition the mutex
wakeup_lock
which is defined and initialized but only for the drivers supporting the
methods above.
If the methods are not present the system behaves as previously
performing a periodic polling of the events queue.
The blocking call is disabled if a joystick or sensor is detected
and falls back to previous behavior.
On Wayland -- or at least on some Wayland implementations -- windows
aren't shown until something has been rendered into them. For the
'testmessage' test program, this means that the final messagebox (a
modal one) is blocking an "invisible window", which can then be
difficult to close.
By creating a renderer and presenting once, the window is properly
displayed, and the test behaves as it does under X11 (including
XWayland).
This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(),
SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new
SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise
this functionality and makes a minor fix to X11 that I missed in
https://hg.libsdl.org/SDL/rev/02a2d609369b
To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to
SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards
compatibility with older code.
SDL_SemPost() was called by the FIFO threads after the semaphore was
freed because the main thread actually synchronized on the
`writerRunning`/`readersRunning` count and not the semaphores itself.
- acinclude/alsa.m4, esd.m4: Ran through autoupdate to replace several
AC_TRY_[COMPILE|LINK|RUN] with corresponding AC_???_IFELSE , so that
autoconf-2.70 doesn't warn.
- sdl2.m4: Ditto.
- test/acinclude.m4 (sdl2): Ditto.
- remove HP/UX 9 (%@#!) support
- change fopen() mode from "a" to "w" in test code.
- bump its serial num to 2.
- test/acinclude.m4: same sdl2.m4 updates.
Specifically this patch which does not invoke _AC_PATH_X_XMKMF and
_AC_PATH_X_DIRECT internal autoconf routines when cross-compiling:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=33c3a47c04ab70a4dd54963fe433a171bc03747f
Without this, CFLAGS would brokenly have system include paths like
-I/usr/include/X11 when cross-compiling e.g. for windows. (And it
also resulted in annoying imake crashes for my setup...)
configure output is practically unchanged. there are still lots of
AC_TRY_COMPILE/AC_TRY_LINK replacements needed to really eliminate
the warnings, but that's for another time.
- SDL_video.c (SDL_ShowMessageBox): replace messageboxdata, set title
or message field to "" if either of them is NULL.
- SDL_video.c (SDL_ShowSimpleMessageBox): set title or message to ""
if either of them is NULL for EMSCRIPTEN builds.
- SDL_bmessagebox.cc: add empty string check along with NULL check for
title and message fields.
- SDL_windowsmessagebox.c (AddDialogString): remove NULL string check
- SDL_windowsmessagebox.c (AddDialogControl): add empty string check
along with the NULL check.
- SDL_x11messagebox.c: revert commit 677c4cd68069
- SDL_os2messagebox.c: revert commit 2c2a489d76e7
- test/testmessage.c: Add NULL title and NULL message tests.
Added support for the PS4 controller gyro and accelerometer on iOS and HIDAPI drivers
Also fixed an issue with the accelerometer on iOS having inverted axes
This uses pre-recorded evdev capabilities, so that we can check for
regressions without the devices having to be physically present.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Xbox Elite controllers use AUX1-AUX4 to represent the paddle buttons when using the HIDAPI driver
PS4 and PS5 controllers use AUX1 to represent the touchpad button
Nintendo Switch Pro controllers use AUX1 to represent the capture button
This driver supports the Razer Atrox Arcade Stick
Some of the quirks of this driver, inherent in Windows Gaming Input:
* There will never appear to be controllers connected at startup. You must support hot-plugging in order to see these controllers.
* You can't read the state of the guide button
* You can't get controller events in the background
The warnings were produced by GCC 9.2.x for x86_64-linux-gnu or
i386-pc-msdosdjgpp targets.
Most of the fixes involve changing the type of a variable rather than
the format specifier. For many of the affected test conuter variables,
a basic int seems sufficient.
Some format specifier warnings still remain for cases where changing
type or casting seemed inappropriate. Those warnings will probably
require some new format specifier macros (e.g. SDL_PRIu32).
DominikD
There are several tests that need resources in the output directory to work:
* `testiconv` depends on `utf8.txt`
* `testoverlay2` and `teststreaming` depend on `moose.dat`
This patch adds these two files to the `RESOURCE_FILES` variable.
One could also copy `shapes\*.bmp` over to the output directory for `testshape` to use but this patch doesn't do that for three reasons:
* executable takes path as an argument and doesn't need these files side by side
* these are ~45MB and copying them over would cause build directory to swell
* there are already files in the output directory that can be used with this test (`sample.bmp` and `button.bmp`)
Sam Lantinga
Vladislav Dmitrievich Turbanov
Eric Wasylishen
Ozkan Sezer
Francesco Abbate
Ryan C. Gordon
Christian Rauch
David Gow
Vanfanel
Cameron Cawley
Erik Yuzwa
Vladislav Dmitrievich Turbanov
Cameron Gutman
Sylvain Becker
Joel Linn
Simon McVittie
Jay Petacat