"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.
Cameron Gutman
The bugfix in https://hg.libsdl.org/SDL/rev/ca9417a52f18 caused SDL_SetRelativeMouseMode() to begin failing on Vivante (Steam Link). Even though Vivante doesn't have a SetRelativeMouseMode() or WarpMouse() function, it's in relative mode already (because it uses evdev) so the function was actually working as intended.
I think providing a no-op SetRelativeMouseMode() function for Vivante is a reasonable fix. Since it's already getting relative events through evdev, it really is a no-op to "enter relative mode".
In fact, this is probably the right thing to do for all backends that use evdev (vivante, raspberry, and kmsdrm). Raspberry and kmsdrm both have WarpMouse() implementations so SDL_SetRelativeMouseMode() isn't failing there, but it still seems to make sense not to have to do the fake warping if they're evdev-based anyway.
Manuel Sabogal
There is an issue on the latest commit of the mercurial repo when SDL_THREADS_DISABLED is set:
src/core/linux/SDL_threadprio.c:79:28: error: unknown type name 'Sint64'; did you mean 'int'
Jan Martin Mikkelsen
The attached patch adds support for single-touch evdev devices.
These devices report ABS_X, ABS_Y and BTN_TOUCH events. This patch sets them up as MT devices with a single slot and handles the appropriate messages.
Jan Martin Mikkelsen
The file src/core/linux/SDL_evdev.c uses the Linux specific types __u32 and __s32. This breaks things on FreeBSD when building with evdev.
Sylvain 2019-04-18 21:22:59 UTC
Changes:
- SDL_WINDOWEVENT_FOCUS_GAINED and SDL_WINDOWEVENT_FOCUS_LOST are sent when the java method onWindowFocusChanged() is called.
- If we have support for MultiWindow (eg API >= 24), SDL event loop is blocked/un-blocked (or simply egl-backed-up or not), when java onStart()/onStop() are called.
- If not, this behaves like now, SDL event loop is blocked/un-blocked when onPause()/onResume() are called.
So if we have two app on screen and switch from one to the other, only FOCUS events are sent (and onPause()/onResume() are called but empty. onStart()/onStop() are not called).
The SDL app, un-focused, would still continue to run and display frames (currently the App would be displayed, but paused).
Like a video player app or a chronometer that would still be refreshed, even if the window hasn't the focus.
It should work also on ChromeBooks (not tested), with two apps opened at the same time.
I am not sure this fix Dan's issue. Because focus lost event triggers Minimize function (which BTW is not provided on android).
https://hg.libsdl.org/SDL/file/bb41b3635c34/src/video/SDL_video.c#l2653https://hg.libsdl.org/SDL/file/bb41b3635c34/src/video/SDL_video.c#l2634
So, in addition, it would need to add by default SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS to 0.
So that the lost focus event doesn't try to minimize the window. And this should fix also the issue.
java layer runs as if separate mouse and touch was 1,
Use SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS
for generating synthetic touch/mouse events
Only two chars are used but the full prototype is:
int tioclinux(struct tty_struct *tty, unsigned long arg)
==5010== Syscall param ioctl(TIOCLINUX) points to uninitialised byte(s)
==5010== at 0x53E73C7: ioctl (syscall-template.S:78)
==5010== by 0x4A887DA: SDL_EVDEV_Init (SDL_evdev.c:163)
==5010== by 0x4A7D157: KMSDRM_VideoInit (SDL_kmsdrmvideo.c:509)
==5010== by 0x497D959: SDL_VideoInit_REAL (SDL_video.c:529)
==5010== by 0x487ACBC: SDL_InitSubSystem_REAL (SDL.c:171)
==5010== by 0x487B052: SDL_Init_REAL (SDL.c:256)
==5010== by 0x488F7D6: SDL_Init (SDL_dynapi_procs.h:85)
by checking Android_Window validity
- SDLThread: user application is exiting:
SDL_VideoQuit() and clearing SDL_GetVideoDevice()
- ActivityThread is changing orientation/size
surfaceChanged() > Android_SetScreenResolution() > SDL_GetVideoDevice()
- Separate function into Android_SetScreenResolution() and Android_SendResize(),
formating, and mark Android_DeviceWidth/Heigh as static
This also solves reports of this log message:
"INFO: The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL forums/mailing list
<https://discourse.libsdl.org/> EVDEV KeyCode 330"
(EVDEV KeyCode 330 is BTN_TOUCH.)
Fixes Bugzilla #4147.
- If you call onPause() before CreateWindow(), SDLThread will run in infinite loop in background.
- If you call onPause() between a DestroyWindow() and a new CreateWindow(), semaphores are invalids.
SDLActivity.java: the first resume() starts the SDLThread, don't call
nativeResume() as it would post ResumeSem. And the first pause would
automatically be resumed.
- Currently, it tries to Attach the JVM first and update the thread local storage, which are two operations.
Now, it simply gives back the JNI Env stored for the thread.
- Android_JNI_SetupThreadi() should only be used for external.
For internal SDL thread, it's already called in RunThread() (SDL_systhread.c),
and other thread are Java threads which don't need to be attached. i
(even if it doesn't hurt to do it, since it's a no-op).
- JNI_OnLoad is filled with pthread_create, GetEnv, AttachCurrentThread...
It's called for all shared libraries which may don't want this setup,
and loading libraries can be also modified to be done from a static context,
or with relinker. So it's not really clear how, who and what it sets up.
=> Reduce this function to the minimal
SDLThread is a Java Thread, it's not needed to call 'Detach' from the JVM.
Clear mThreadKey, so that the pthread_create destructor is not called for this
thread.
SDLActivity thread priority is unchanged, by default -10 (THREAD_PRIORITY_VIDEO).
SDLAudio thread priority was -4 (SDL_SetThreadPriority was ignored) and is now -16 (THREAD_PRIORITY_AUDIO).
SDLThread thread priority was 0 (THREAD_PRIORITY_DEFAULT) and is -4 (THREAD_PRIORITY_DISPLAY).
- destroy Android_ActivityMutex
- display any SDL error message that may have occured in this thread,
since SDL_GetError() is thread specific, and user has no access to it.
In the usual case, first call to onNativeOrientationChanged() is done before
SDL has been initialised and would just set an error message
"Video subsystem has not been initialized" without sending the event.
Make sure there is not pending Pause accumulated, so the the application doesn't
remain paused and stucked in onDestroy().
Can be tested by adding:
SDLActivity.nativePause();
SDLActivity.nativePause();
mSingleton.finish();
Doesn't seem to happen manually, but symetrical to the pause handling.
Can be tested by adding:
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
Before, it ends in 'paused' state.
Now, it ends in 'resumed' state.
It may happen to have the sequence pause()/resume()/pause(), before polling
any events.
Before, it ends in 'resumed' state because as the check is greedy.
Now, always increase the Pause semaphore, and stop at each pause.
It ends in 'paused' state.
Related to bug 3250: set up a reconfiguration of SurfaceView holder.
Turn the screen off manually before the app starts
(repro rate is not 100%..)
Use a semaphore to prevent concurrency issues between Java Activity and Native thread code, when using 'Android_Window'.
(Eg. Java sending Touch events, while native code is destroying the main SDL_Window. )
Sylvain Becker
Ozkan Sezer
Sam Lantinga
Ryan C. Gordon
Fabrice Fontaine
Alex Szpakowski