AC_CONFIG_AUX_DIRS is an undocumented, internal version of
AC_CONFIG_AUX_DIR that takes a whitespace-separated list, instead of a
single path to add to the list. It also does not automatically treat
the given path as being relative to the $srcdir, unlike the documented
AC_CONFIG_AUX_DIR.
Newer versions of autoconf treat the argument to AC_CONFIG_AUX_DIRS
as being literal (they do not expand the shell variable), causing
autoreconf to fail if $srcdir is explicitly specified. The argument to
AC_CONFIG_AUX_DIR is checked relative to $srcdir anyway, so there is no
need to specify $srcdir a second time.
Resolves: https://github.com/libsdl-org/SDL/issues/4719
Signed-off-by: Simon McVittie <smcv@debian.org>
[--use-rendergeometry mode1|mode2]
mode1: Draw sprite2 as triangles that can be recombined as rect by software renderer
mode2: Draw sprite2 as triangles that can *not* be recombined as rect by software renderer
Use an 'indices' array
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
On Wayland -- or at least on some Wayland implementations -- windows
aren't shown until something has been rendered into them. For the
'checkkeys' test program, this means that keyboard input isn't
registered, making the program rather useless.
By creating a renderer and presenting once, the window is properly
displayed, and the test behaves as it does under X11 (including
XWayland).
The exact same thing was done with testmessge in 1cd97e2695 (PR #4252)
SDL_Vulkan_GetDrawableSize() doesn't always return a size which is
within the Vulkan swapchain's allowed image extent range.
(This happens on X11 a lot when resizing, which is bug #3287)
Clamp the value we get back from SDL_Vulkan_GetDrawableSize() to this
range. Given the range usually is just a single value, this is almost
always equivalent to just using the min or max image extent, but this
seems logically most correct.
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.
Ozkan Sezer
Simon McVittie
Ryan C. Gordon
Lionel Landwerlin
Sylvain
David Gow
Sam Lantinga
Cameron Cawley
Vladislav Dmitrievich Turbanov
Eric Wasylishen
Francesco Abbate
Christian Rauch
Vanfanel
Erik Yuzwa
Vladislav Dmitrievich Turbanov
Cameron Gutman