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.
