SDL/test/checkkeysthreads.c

311 lines
8.1 KiB
C
Raw Normal View History

Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/*
2023-01-09 10:41:41 -07:00
Copyright (C) 1997-2023 Sam Lantinga <slouken@libsdl.org>
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely.
*/
/* Simple program: Loop, watching keystrokes
Note that you need to call SDL_PollEvent() or SDL_WaitEvent() to
pump the event loop and catch keystrokes.
*/
#include <stdio.h>
#include <stdlib.h>
#ifdef __EMSCRIPTEN__
#include <emscripten/emscripten.h>
#endif
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>
#include <SDL3/SDL_test.h>
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
static int done;
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/* Call this instead of exit(), so we can clean up SDL: atexit() is evil. */
static void
quit(int rc)
{
SDL_Quit();
/* Let 'main()' return normally */
if (rc != 0) {
exit(rc);
}
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
static void
print_string(char **text, size_t *maxlen, const char *fmt, ...)
{
int len;
va_list ap;
va_start(ap, fmt);
len = SDL_vsnprintf(*text, *maxlen, fmt, ap);
if (len > 0) {
*text += len;
if (((size_t)len) < *maxlen) {
*maxlen -= (size_t)len;
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
} else {
*maxlen = 0;
}
}
va_end(ap);
}
static void
print_modifiers(char **text, size_t *maxlen)
{
int mod;
print_string(text, maxlen, " modifiers:");
mod = SDL_GetModState();
if (!mod) {
print_string(text, maxlen, " (none)");
return;
}
if (mod & SDL_KMOD_LSHIFT) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " LSHIFT");
}
if (mod & SDL_KMOD_RSHIFT) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " RSHIFT");
}
if (mod & SDL_KMOD_LCTRL) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " LCTRL");
}
if (mod & SDL_KMOD_RCTRL) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " RCTRL");
}
if (mod & SDL_KMOD_LALT) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " LALT");
}
if (mod & SDL_KMOD_RALT) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " RALT");
}
if (mod & SDL_KMOD_LGUI) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " LGUI");
}
if (mod & SDL_KMOD_RGUI) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " RGUI");
}
if (mod & SDL_KMOD_NUM) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " NUM");
}
if (mod & SDL_KMOD_CAPS) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " CAPS");
}
if (mod & SDL_KMOD_MODE) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
print_string(text, maxlen, " MODE");
}
if (mod & SDL_KMOD_SCROLL) {
print_string(text, maxlen, " SCROLL");
}
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
static void
PrintModifierState(void)
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
char message[512];
char *spot;
size_t left;
spot = message;
left = sizeof(message);
print_modifiers(&spot, &left);
SDL_Log("Initial state:%s\n", message);
}
static void
PrintKey(SDL_Keysym *sym, SDL_bool pressed, SDL_bool repeat)
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
char message[512];
char *spot;
size_t left;
spot = message;
left = sizeof(message);
/* Print the keycode, name and state */
if (sym->sym) {
print_string(&spot, &left,
"Key %s: scancode %d = %s, keycode 0x%08X = %s ",
pressed ? "pressed " : "released",
sym->scancode,
SDL_GetScancodeName(sym->scancode),
sym->sym, SDL_GetKeyName(sym->sym));
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
} else {
print_string(&spot, &left,
"Unknown Key (scancode %d = %s) %s ",
sym->scancode,
SDL_GetScancodeName(sym->scancode),
pressed ? "pressed " : "released");
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
print_modifiers(&spot, &left);
if (repeat) {
print_string(&spot, &left, " (repeat)");
}
SDL_Log("%s\n", message);
}
static void
2021-11-19 15:02:02 -07:00
PrintText(const char *eventtype, const char *text)
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
2021-11-19 15:02:02 -07:00
const char *spot;
char expanded[1024];
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
expanded[0] = '\0';
for (spot = text; *spot; ++spot) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
size_t length = SDL_strlen(expanded);
(void)SDL_snprintf(expanded + length, sizeof(expanded) - length, "\\x%.2x", (unsigned char)*spot);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
SDL_Log("%s Text (%s): \"%s%s\"\n", eventtype, expanded, *text == '"' ? "\\" : "", text);
}
static void loop(void)
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
SDL_Event event;
/* Check for events */
/*SDL_WaitEvent(&event); emscripten does not like waiting*/
2022-12-01 14:07:03 -07:00
(void)fprintf(stderr, "starting loop\n");
(void)fflush(stderr);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
while (!done && SDL_WaitEvent(&event)) {
2022-12-01 14:07:03 -07:00
SDL_Log("Got event type: %" SDL_PRIu32 "\n", event.type);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
switch (event.type) {
case SDL_EVENT_KEY_DOWN:
case SDL_EVENT_KEY_UP:
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
PrintKey(&event.key.keysym, (event.key.state == SDL_PRESSED) ? SDL_TRUE : SDL_FALSE, (event.key.repeat) ? SDL_TRUE : SDL_FALSE);
break;
case SDL_EVENT_TEXT_EDITING:
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
PrintText("EDIT", event.text.text);
break;
case SDL_EVENT_TEXT_INPUT:
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
PrintText("INPUT", event.text.text);
break;
case SDL_EVENT_MOUSE_BUTTON_DOWN:
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/* Left button quits the app, other buttons toggles text input */
2022-12-01 14:07:03 -07:00
(void)fprintf(stderr, "mouse button down button: %d (LEFT=%d)\n", event.button.button, SDL_BUTTON_LEFT);
(void)fflush(stderr);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
if (event.button.button == SDL_BUTTON_LEFT) {
done = 1;
} else {
if (SDL_TextInputActive()) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
SDL_Log("Stopping text input\n");
SDL_StopTextInput();
} else {
SDL_Log("Starting text input\n");
SDL_StartTextInput();
}
}
break;
case SDL_EVENT_QUIT:
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
done = 1;
break;
default:
break;
}
2022-12-01 14:07:03 -07:00
(void)fprintf(stderr, "waiting new event\n");
(void)fflush(stderr);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
2022-12-01 14:07:03 -07:00
(void)fprintf(stderr, "exiting event loop\n");
(void)fflush(stderr);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
#ifdef __EMSCRIPTEN__
if (done) {
emscripten_cancel_main_loop();
}
#endif
}
/* Very simple thread - counts 0 to 9 delaying 50ms between increments */
static int SDLCALL ping_thread(void *ptr)
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
int cnt;
SDL_Event sdlevent;
SDL_memset(&sdlevent, 0, sizeof(SDL_Event));
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
for (cnt = 0; cnt < 10; ++cnt) {
2022-12-01 14:07:03 -07:00
(void)fprintf(stderr, "sending event (%d/%d) from thread.\n", cnt + 1, 10);
(void)fflush(stderr);
sdlevent.type = SDL_EVENT_KEY_DOWN;
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
sdlevent.key.keysym.sym = SDLK_1;
SDL_PushEvent(&sdlevent);
SDL_Delay(1000 + rand() % 1000);
}
return cnt;
}
int main(int argc, char *argv[])
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
{
SDL_Window *window;
SDL_Renderer *renderer;
SDL_Thread *thread;
SDLTest_CommonState *state;
/* Initialize test framework */
state = SDLTest_CommonCreateState(argv, 0);
if (state == NULL) {
return 1;
}
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/* Enable standard application logging */
SDL_LogSetPriority(SDL_LOG_CATEGORY_APPLICATION, SDL_LOG_PRIORITY_INFO);
/* Parse commandline */
if (!SDLTest_CommonDefaultArgs(state, argc, argv)) {
return 1;
}
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/* Initialize SDL */
if (SDL_Init(SDL_INIT_VIDEO) < 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't initialize SDL: %s\n", SDL_GetError());
return 1;
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}
/* Set 640x480 video mode */
window = SDL_CreateWindow("CheckKeys Test", 640, 480, 0);
if (window == NULL) {
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't create 640x480 window: %s\n",
SDL_GetError());
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
quit(2);
}
/* On wayland, no window will actually show until something has
actually been displayed.
*/
renderer = SDL_CreateRenderer(window, NULL, 0);
SDL_RenderPresent(renderer);
Fix uses of undefined macro identifiers (-Wundef) * Fix -Wundef warnings due to use of unguarded SDL_LOADSO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_LOADSO_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_COCOA * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_UIKIT * Fix -Wundef warnings due to use of unguarded SDL_TIMERS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_EVENTS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_TIMER_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_SENSOR_DISABLED * Fix -Wundef warnings due to use of unguarded __ANDROID__ * Fix -Wundef warnings due to use of unguarded __IOS__ * Fix -Wundef warnings due to use of unguarded EMULATE_CAS * Fix -Wundef warnings due to use of unguarded SDL_ATOMIC_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_THREADS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_SNDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_NETBSD * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_WASAPI * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DSOUND * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_COREAUDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_AAUDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_OPENSLES * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PSP * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_VITA * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_N3DS * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_NEON_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_ALTIVEC_BLITTERS * Fix -Wundef warnings due to use of unguarded __VITA__ * Fix -Wundef warnings due to use of unguarded __3DS__ * Fix -Wundef warnings due to use of unguarded SDL_DYNAPI_PROC_NO_VARARGS * Fix -Wundef warnings due to use of unguarded __APPLE__ * Fix -Wundef warnings due to use of unguarded __WINRT__ * Fix -Wundef warnings due to use of unguarded SDL_HIDAPI_DISABLED * Fix -Wundef warnings due to use of unguarded __TVOS__ * Fix -Wundef warnings due to use of unguarded HAVE_DRIVER_BACKEND * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_XINPUT * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_WGI * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_DINPUT * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_MFI * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_PS2 * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_PSP * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_VITA * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_N3DS * Fix -Wundef warnings due to use of unguarded __MACOS__ * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WINRT * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RPI * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PVR_OGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VIVANTE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D11 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D12 * Fix -Wundef warnings due to use of unguarded SDL_RENDER_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_METAL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_PSP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_VITA_GXM * Fix -Wundef warnings due to use of unguarded SDL_ARM_SIMD_BLITTERS * Fix -Wundef warnings due to use of unguarded SDL_ARM_NEON_BLITTERS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_PSP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VITA * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_N3DS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_KMSDRM * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RISCOS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_NGAGE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_METAL * Fix -Wundef warnings due to use of unguarded SDL_LSX_INTRINSICS * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_NP_H * Fix -Wundef warnings due to use of unguarded __RISCOS__ * Fix -Wundef warnings due to use of unguarded FAKE_RECURSIVE_MUTEX * Fix -Wundef warnings due to use of unguarded USE_POSIX_SPAWN * textureData is only needed when SDL is built with YUV support * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_ALSA * Fix -Wundef warnings due to use of unguarded SDL_SSE3_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE4_2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE4_1_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX512F_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_MMX_INTRINSICS * Fix -Wundef warnings due to use of unguarded HAVE_CLOCK_GETTIME * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DISK * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_DUMMY * Fix -Wundef warnings due to use of unguarded HAVE_GCC_ATOMICS * Fix -Wundef warnings due to use of unguarded HAVE_GCC_SYNC_LOCK_TEST_AND_SET * Fix -Wundef warnings due to use of unguarded SDL_USE_LIBDBUS * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_JACK * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_VIRTUAL * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_LINUX * Fix -Wundef warnings due to use of unguarded HAVE_LIBC * Fix -Wundef warnings due to disabling SDL_LIBC * Fix -Wundef warnings due to use of unguarded HAVE_PLATFORM_BACKEND * Fix -Wundef warnings due to use of unguarded DEBUG * Fix -Wundef warnings due to use of unguarded HAVE_LINUX_INPUT_H * Fix -Werror=unused-variable when building with SDL_LIBC=OFF * Fix -Wundef warnings due to use of unguqrded SDL_USE_LIBUDEV * Use SDL alloc functions in libusb/hid.c * Fix -Wundef warnings due to use of unguarded HAVE_LIBUDEV_H * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VULKAN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_OFFSCREEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_OGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_GLX * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_OGL_ES2 * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_OSS * Remove SDL_AUDIO_DRIVER_SUNAUDIO reference since it is never set * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PIPEWIRE * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PULSEAUDIO * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XCURSOR * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XDBE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XFIXES * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XINPUT2 * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XINPUT2_SUPPORTS_MULTITOUCH * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XRANDR * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XSCRNSAVER * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XSHAPE * Don't call XShape functions when XShape is diabled * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WAYLAND * Fix -Wundef warnings due to use of unuarded SDL_VIDEO_DRIVER_X11 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RISCOS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_EGL * Disable array when compiled with SDL_EVENTS=OFF * Fix -Wundef warnings due to use of unguarded SDL_INPUT_LINUXEV * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD * Fix -Wundef warnings due to use of unguarded SDL_THREAD_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PS2 * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PSP * Fix -Wundef warnings due to use of unguarded SDL_THREAD_VITA * Fix -Wundef warnings due to use of unguarded SDL_THREAD_N3DS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_STDCPP * Fix -Wundef warnings due to use of unguarded SDL_THREAD_NGAGE * Fix -Wundef warnings due to use of unguarded __WINDOWS__ * Fix -Wundef warnings due to use of unguarded __WINGDK__ * Fix -Wundef warnings due to use of unguarded __ANDROID__ * Fix -Wundef warnings due to use of unguarded SDL_THREAD_GENERIC_COND_SUFFIX * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PIB * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PVR * Fix -Wundef warnings due to use of unguarded SDL_FILE_DISABLED * Fix -Wundef warnings due to use of unguarded __XBOXONE__ * Fix -Wundef warnings due to use of unguarded __XBOXSERIES__ * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_WGL * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_QNX * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DISK * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_QNX * Fix -Wundef warnings due to use of unguarded DEBUG_RAZOR * Fix -Wundef warnings due to use of unguarded WINAPI_FAMILY_PHONE_APP * Fix -Wundef warnings due to use of unguarded SDL_MAC_NO_SANDBOX * Fix -Wundef warnings due to use of unguarded __(IPHONE|APPLETV|MAC)_OS_VERSION_MAX_ALLOWED * Fix C4090 warning ('function': different 'const' qualifiers) * ci: use -isystem for include dirs of pspdev toolchain * cmake: add -Wundef option * Fix remaining -Wundef warnings due to use of unguarded SDL_VIDEO_VULKAN and SDL_VIDEO_METAL * Fix -Wundef warnings due to use of unguarded __MACOS__ * DEBUG_CONVERT is guaranteed to be defined in src/audio/SDL_audiocvt.c * Fix -Wundef warnings due to use of unguarded HAVE_NANOSLEEP * Fix -Wundef warnings due to use of unguarded HAVE_DXGI_H * Fix -Wundef warnings due to use of unguarded HAVE_LINUX_INPUT_H * fix SDL_VIDEO_DRIVER_WAYLAND * fix SDL_VIDEO_DRIVER_X11 * Fix -Wundef warnings due to use of unguarded HAVE_MMDEVICEAPI_H * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_SETNAME_NP * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_SET_NAME_NP * Fix -Wundef warnings due to use of unguarded HAVE_SETJMP * Fix -Wundef warnings due to use of unguarded HAVE_SIGNAL_H * Fix -Wundef warnings due to use of unguarded HAVE_TPCSHRD_H * Fix -Wundef warnings due to use of unguarded MACOSX_COREAUDIO * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_DINPUT * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_IOKIT * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_XINPUT * Fix -Wundef warnings due to use of unguarded SDL_IPHONE_KEYBOARD * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_RAWINPUT * Fix -Wundef warnings due to use of unguarded SDL_POWER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_POWER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_POWER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_POWER_LINUX * Fix -Wundef warnings due to use of unguarded SDL_POWER_MACOSX * Fix -Wundef warnings due to use of unguarded SDL_POWER_PSP * Fix -Wundef warnings due to use of unguarded SDL_POWER_UIKIT * Fix -Wundef warnings due to use of unguarded SDL_POWER_VITA * Fix -Wundef warnings due to use of unguarded SDL_POWER_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD_RECURSIVE_MUTEX * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD_RECURSIVE_MUTEX_NP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VIVANTE_VDK * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WAYLAND * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_HAS_XKBKEYCODETOKEYSYM * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_SUPPORTS_GENERIC_EVENTS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_CGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_EGL * Fix -Wundef warnings due to use of unguarded __MACOS__ * Fix -Wundef warnings due to use of unguarded __OpenBSD__ * Fix -Wundef warnings due to use of unguarded __FreeBSD__ * Fix -Wundef warnings due to use of unguarded __MWERKS__ * Fix -Wundef warnings due to use of unguarded __WIN32__ * Fix -Wundef warnings due to use of unguarded SDL_IPHONE_LAUNCHSCREEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES2 * Remove unused HAVE_CONST, HAVE_INLINE and HAVE_VOLATILE * Revert "Use SDL alloc functions in libusb/hid.c" This reverts commit 847c64b00da12ca08bef9e947eb948e378eeaef8. * Handle FAKE_RECURSIVE_MUTEX in similar way as SDL2 * Don't use defined in macro
2023-03-29 15:49:01 -06:00
#ifdef __IOS__
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
/* Creating the context creates the view, which we need to show keyboard */
SDL_GL_CreateContext(window);
#endif
SDL_StartTextInput();
/* Print initial modifier state */
SDL_PumpEvents();
PrintModifierState();
/* Watch keystrokes */
done = 0;
2022-12-01 14:07:03 -07:00
thread = SDL_CreateThread(ping_thread, "PingThread", NULL);
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
#ifdef __EMSCRIPTEN__
emscripten_set_main_loop(loop, 0, 1);
#else
while (!done) {
loop();
}
#endif
SDL_WaitThread(thread, NULL);
SDL_Quit();
SDLTest_CommonDestroyState(state);
return 0;
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling 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.
2021-03-12 13:58:20 -07:00
}