* Add initial support for the Nokia N-Gage
* N-Gage: disable clipping for the time being, issue needs to be resolved later
* Move va_copy definition to SDL_internal.h
* Move stdlib.h include to SDL_config_ngage.h, much cleaner this way
* Remove redundant include, add HAVE_STDLIB_H
* Revert "N-Gage: disable clipping for the time being, issue needs to be resolved later"
This reverts commit 4f5f0fc36cc7f34fad05e45671dfa7b8dc32fd51.
* N-Gage: fix clipping issue by providing proper math functions
Every other backend does this, so this should match, now.
It's possible this was harmless, but we can avoid the system call
and the (likely?) debug message when it fails, though!
It's marked as being a public symbol internally, however, it was missing from the header files and not visible in the shared library. This adds it to the necessary headers and to the DynAPI list to expose it for use by applications.
Co-authored-by: Frank Praznik <frank.praznik@oh.rr.com>
Vista and later provide the SleepConditionVariableCS() function for this.
Since SDL_syscond_srw.c doesn't require SRW locks anymore, rename it to
SDL_syscond_cv.c which better reflects the implementation of condition
variables rather than the implementation of mutexes.
Fixes#4051.
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
commit 6b8f933589aa3925978a23e77a305a7e89c6ae4a
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:31:29 2021 +0800
update the dynapi by `gendynapi.pl`
commit ebd1790c19983b652713f40ab1e139e485e1a2b7
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:17:48 2021 +0800
revert the change in src/dynapi
commit 734b5f85c1613070081e39238e84198128971b53
Merge: 5a56e5a8 5ac6bd54
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:14:40 2021 +0800
Merge remote-tracking branch 'libsdl/main' into jixingcn
commit 5a56e5a8227d9cff6b497b681c618a76bec1cae1
Author: Xing Ji <jixingcn@gmail.com>
Date: Mon Mar 22 23:55:10 2021 +0800
Fix#3596, can call the `SDL_TLSCleanup` to cleanup the TLS data when closing the application
Drop include of SDL_platform.h as SDL_plaform.h is already included by
SDL_internal.h -> SDL_config.h -> SDL_platform.h
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
When SleepConditionVariableSRW() releases the SRW lock internally, it causes
our SDL_mutex_srw state to become inconsistent. The lock is unowned yet inside,
the owner is still the sleeping thread and more importantly the owner count is
still 1.
The next time someone acquires the lock, they will bump the owner count from 1
to 2. At that point, the lock is hosed. From the internal lock state, it looks
to us like that owner has acquired the lock recursively, even though they have
not. When they call SDL_UnlockMutex(), it will see the owner count > 0 and not
call ReleaseSRWLockExclusive().
Now when someone calls SDL_CondSignal(), SleepConditionVariableSRW() will start
the wakeup process by attempting to re-acquire the SRW lock. This will deadlock
because the lock was never released after the other thread had used it. The
thread waiting on the condition variable will never be able to wake up, even if
the SDL_CondWaitTimeout() function is used and the timeout expires.
Is automatically used when the SRW SDL_mutex implementation is active.
Otherwise falls back to the generic implementation.
v2: - Rebase onto master fa3ea1051a4b
Keep Semaphore Kernel Object impl for Windows 7 and older - choose at runtime
v2: - Fix mixed int/LONG types
- Reorder definitions
- Add missing include
v3: - Use `GetModuleHandle()` to load the API Set
v2: - Add SRW definitions as suggested by Ozkan Sezer
Allows building against older platform headers.
- Rename "hidden" function parameter `mutex_` to `_mutex`
v3: - Use GetModuleHandle instead of LoadLibrary
- Fix typo in comment
SDL_systhread.c and SDL_syslocale.c used to call LoadLibrary() without
calling FreeLibrary() later. GetModuleHandleW() should always succeed
because GetModuleHandleW() itself is imported from kernel32.dll and we
don't need to bother releasing it.
As the name suggests, the hint should only apply to SDL_THREAD_PRIORITY_TIME_CRITICAL
The resulting priorities for my current distro result in these values:
| High | Time Critical
Hint |--------------|-----------------
0 | P=10 N=-10 | P=5 N=-15
1 | P=10 N=-10 | P=-21 N=0
When we request realtime priority from rtkit, we have a rttime limit. If we exceed
that limit, the kernel will send SIGKILL to the process to terminate it.
This isn't something that most high priority processes will want, only processes
that selectively opt into SCHED_RR/FIFO through SDL_HINT_THREAD_PRIORITY_POLICY
should be subject to this level of scrutiny.
This change:
* Switches non-apple posix OSs to use SCHED_OTHER instead of SCHED_RR
for SDL_THREAD_PRIORITY_HIGH/SDL_THREAD_PRIORITY_TIME_CRITICAL.
* Fixes using a hardcoded RLIMIT_RTTIME, instead queries it from rtkit
* Only sets RLIMIT_RTTIME for MakeRealtime rtkit requests
* Adds a note regarding the possible SIGKILL with SDL_HINT_THREAD_PRIORITY_POLICY
* Introduces SDL_HINT_THREAD_FORCE_REALTIME_TIME_CRITICAL to allow apps to acquire realtime scheduling policies on Linux
- video: VideoBootStrap->available() is gone.
- thread: all important SDL_CreateThread internal data now put into
struct SDL_Thread: changes to SDL_SYS_CreateThread().