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
Debugging inside rtkit showed we were failing the RLIMIT_RTTIME check, now that we're asking for realtime and not just high-priority due to a change in SDL.
Between that and the DBus code in SDL being wrong in previous changelist I'm not sure how this could have ever worked.
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Docs:
http://git.0pointer.net/rtkit.git/tree/README
CLIENTS:
To be able to make use of realtime scheduling clients may
request so with a small D-Bus interface that is accessible on
the interface org.freedesktop.RealtimeKit1 as object
/org/freedesktop/RealtimeKit1 on the service
org.freedesktop.RealtimeKit1:
void MakeThreadRealtime(u64 thread_id, u32 priority);
void MakeThreadHighPriority(u64 thread_id, s32 priority);
"In the second half of 2021, new apps will be required to publish with the Android App Bundle on Google Play"
(see https://developer.android.com/guide/app-bundle)
And "Android App Bundles don't support APK expansion (*.obb) files".
Manuel Alfayate Corchete
I'm trying to build SDL2 with threads support here in GNU/Linux, both X86 and ARM, and it does not seem to be possible ATM:
/home/manuel/src/SDLLLL/src/core/linux/SDL_threadprio.c:233:26: error: 'rtkit_max_realtime_priority' undeclared (first use in this function)
1. Comment that SDL_SetThreadPriority will make any necessary system changes when applying priority.
2. Add a hint to override SDL's default behavior for scheduler policy.
3. Modify the pthreads SDL_SetThreadPriority so that instead of just using the current thread scheduler policy it will change it to a policy that should work best for the requested priority.
4. Add hint checks in SDL_SetThreadPriority so that #3 can be overridden if desired.
5. Modify the Linux SDL_SetThreadPriority so that in the case that policy, either by SDL defaults or from the hint, is a realtime policy it uses the realtime rtkit API.
6. Prior to calling rtkit on Linux make the necessary thread state changes that rtkit requires. Currently this is done every time as it isn't expected that SDL_SetThreadPriority will be called repeatedly for a thread.
wengxt
Due to the new major fcitx version is coming close, the existing code need to be ported to use new Fcitx dbus interface.
The new dbus interface is supported by both fcitx 4 and 5, and has a good side effect, which is that it will work with flatpak for free. Also the patch remove the dependency on fcitx header. Instead, it just hardcodes a few enum value in the code so need to handle the different header for fcitx4 or 5.
The first terminator is for input parameters. The second terminator was for the
output parameters.
If an error occurs when calling MakeThreadHighPriority(), e.g. a bad thread id,
then the reply from connection_send_with_reply_and_block() will be null.
There are multiple SDL APIs that internally sink into dbus calls, e.g. battery
status, thread priority. If those calls happen in different threads simultaneously
it can result in dbus crashes.
To abide by dbus's multithreading guidelines we must call dbus_threads_init_default()
to enable dbus's internal locking mechanisms:
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#gac7b8a7001befc3eaa8c6b043151008dc
Additionally, access to a DBusMessage must be synchronized between threads.
SDL was already abiding that guideline as the DBusMessage structs aren't shared.
The following email from the dbus mailing list hints that arbitrating access to
the DBusConnection on the SDL may also be required:
https://lists.freedesktop.org/archives/dbus/2017-September/017306.html
Currently the message is double terminated, which results in SDL_DBus_CallMethodInternal()
incorrectly assuming that the other party is always returning true.
I'm not super familiar with dbus, so I'm not sure if this could also be the cause of this bug:
https://github.com/ValveSoftware/steam-for-linux/issues/6901
Add an include on SDL_error.h to avoid the following build failure
without threads:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: build/.libs/SDL_threadprio.o: in function `SDL_LinuxSetThreadPriority_REAL':
SDL_threadprio.c:(.text+0x0): undefined reference to `SDL_Unsupported'
Fixes:
- http://autobuild.buildroot.org/results/7f7712c5bd47de4a3fcec1e0d0526fd5a3ecd532
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Make sure the thread is actually paused, and context backep-up, before
SurfaceView is destroyed (eg surfaceDestroyed() actually returns).
Add a timeout when surfaceDestroyed() is called, and check 'backup_done' variable.
It prevents crashes like:
#00 pc 000000000000c0d0 /system/lib64/libutils.so (android::RefBase::incStrong(void const*) const+8)
#01 pc 000000000000c7f4 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::UpdateBufferList(ANativeWindowBuffer*)+284)
#02 pc 000000000000c390 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::DequeueBuffer()+240)
#03 pc 000000000000bb10 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::GetBuffer(EglSubResource*, EglMemoryDesc*)+64)
#04 pc 000000000032732c /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::UpdateResource(EsxContext*)+116)
#05 pc 0000000000326dd0 /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::GetResource(EsxContext*, EsxResource**, EsxResource**, int)+56)
#06 pc 00000000002ae484 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::AcquireBackBuffer(int)+364)
#07 pc 0000000000249680 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::Clear(unsigned int, unsigned int, unsigned int, EsxClearValues*)+1800)
#08 pc 00000000002cb52c /vendor/lib64/egl/libGLESv2_adreno.so (EsxGlApiParamValidate::GlClear(EsxDispatch*, unsigned int)+132)
Message in the log, when going to background:
"call to OpenGL ES API with no current context (logged once per thread)"
Because of SDL_WINDOWEVENT_MINIMIZED is sent from the Java Activity thread.
It calls SDL_RendererEventWatch(), _WindowEvent() and glFinish() without context.
Solution is to move sending of SDL_WINDOWEVENT_MINIMIZED to the SDL thread.
The SDL_USE_LIBDBUS define is set inside SDL_debug.h, therefore the
circular dependency made it impossible for this feature to be enabled.
Instead, guard SDL_dbus.h based on the autoconf variable HAVE_DBUS_DBUS_H
Additionally, fix one of the rtkit comments. CAP_SYS_NICE isn't required
to achieve high priority. But there is some scheduler config that rtkit
needs the app to setup.
Daniel Drake
A long time ago, it was possible to play neverball on Linux using the accelerometer found in HP laptops.
The kernel exposes the accelerometer as a joystick (/dev/input/jsX) as well as an evdev device (/dev/input/eventX). I guess it worked fine when SDL was using the js interface, but then stopped working here: http://hg.libsdl.org/SDL/rev/fdaeea9e7567
Looking at current code which uses udev to discover joysticks, it looks for the udev tag ID_INPUT_JOYSTICK.
However udev's internal input_id logic specifically tags accelerometers as ID_INPUT_ACCELEROMETER and nothing else.
This looks like a good fit for SDL_HINT_ACCELEROMETER_AS_JOYSTICK.