-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump to SDL2 2.0.10 & extract .java from SDL2 tarball #1779
Conversation
For what it's worth, upstream has still some unfixed Android concurrency issues and stuff regarding SDL_TOUCH_MOUSEID and mouse focus on Android which is making some progress, so I'll keep bumping this up for a while seeing how they progress fixing things. (Unless someone here is really adamant about getting this in super quick) |
Code changes look good to me, but I won't merge for now as you've suggested. Also didn't test with Kivy yet, although I don't anticipate any issues. |
Summary from chat: |
Concurrency issues and ANDROID_ON_PAUSE=0 bugs have been addressed in SDL2 now, at least for the ones I am aware, so I think it's not at a bad spot for a potential merge right now. (Especially since these concurrency issues are still present in 2.0.9 stable which is what we currently use, and ANDROID_ON_PAUSE=0 is not even really possible with that version) Is someone with a complex kivy app interested in testing this by any chance? Things to look out for is mainly touch and multitouch, and if you can a USB hardware mouse (or an app that emulates one) to see if all the input stuff still works as expected. Possible issues could be that the input no longer works for one variant at all, or that clicks are processed twice with one input variant |
Just tested this a bit with my Kivy app, just normal touch interaction but everything seemed fine.
Has the default actually changed here, I couldn't find much information about it? Kivy's SDL2 code does make an effort to deal properly with touch and mouse events independently so it may not even matter, and certainly doesn't if they were separated before, but I don't think it was setting anything non-default.
Do I understand right that the new behaviour (not blocking) remains not the default, so Kivy doesn't need any changes to work as before? Probably we want to change Kivy to work with the non-blocking, but just checking that there's no immediate change for now. |
@inclement yeah defaults are the same. Any default changes were reverted, nothing regarding blocking or touch has changed if no hints are set. Per default they are not separated however, which would mean kivy wouldn't handle mouse wheel and in general act like a hardware mouse is like a finger. That works well enough to use the app but it's not ideal if you want first class mouse support, so if you want that you should look into the new hints |
@Jonast Perfect, in that case it's good to merge as far as I'm concerned. It sounds like Kivy doesn't handle hardware mouse properly on Android, but I bet almost nobody has even tried it, I'll maybe try to fix it since it should be a trivial hint change. |
i rebased this on top of develop branch, and built a simple kivy app
|
full build log: https://gist.github.com/Fak3/647f5c218cab0f2a631726355d36baa9 |
I just tried the most recent sdl from hg: http://hg.libsdl.org/SDL/rev/89b3e1e9839c |
I have disabled multisamples in kivy config and app worked!
|
I tried the latest sdl2 version from hg. It also fixed #1876 |
sdl2 issue with multisampling reported upstream: https://bugzilla.libsdl.org/show_bug.cgi?id=4681 |
Ah, issue with EGL_BAD_SURFACE is more complicated. For more complex app, even without multisampling the chance of successful start is about 30% |
@Fak3 I bumped the SDL2 version to the one with the fix. Can you retest if it works now? (edit: also thanks so much for debugging this with the SDL2 devs 🎉 ❤️ ) I also need to look into the loading screen sometimes not going away, I think that might be a regression of the SDL2 version change |
@Jonast I've been testing with latest sdl for a while. I am also experiencing a bug with app hanging during startup. It only happens on more recent versions of Android (6+ I believe). If you minimize and then maximize app, it will continue the startup normally. Also the new sdl version sometimes results in app being momentarily paused and resumed during startup, which results in the kivy bug, which I have opened pr for: kivy/kivy#6404 |
@Fak3 yeah the startup hang is why I put the So the crash is gone? That's good! 🎉 |
Yes, the crash was fixed in sdl repo. Another issue the new sdl introduces is the weird multisampling + fullscreen jumping bug: #1876 |
I've been debugging the issue with the freeze on startup. This is what I discovered so far: case 1On android 8.1, API 27 app freezes on startup. The last thing in the adb logcat is this:
When case 2On Android 5.1, API 22 app does not freeze. The difference is that mIsResumedCalled is true. |
@Fak3 I think I figured the problem out, it's related to p4a's loading screen code and how it interacts with SDL2's new multi window/side by side handling. Can you give it another try to see if the loading screen works okay for you now? |
Hm. Now I can't build my app, it fails with the weird error:
|
Python error is misleading, actually it fails to find
|
Ah, for anyone hitting similar issue - I am on openSUSE, which ships its own version of yet-unmerged cpython patch for better lib64 support: python/cpython#8068 |
Wait, and why exactly does that break? 😱 Fascinating, is there something we can do about that? |
When p4a calls pip to install packages in So the issue is that p4a hostpython is not properly patched to match my system-wide python installation. I am not sure what would be the proper solution for this. Currenly I managed to workaround this by manually adding |
The issue with startup freeze seems to be fixed. |
Superseded by #2673 |
Bumps SDL2 to the next 2.0.10 release, and fixes the SDL2 bootstrap so it copies
.java
out of the tarball instead of having a copy in our source treeMajor SDL2 fixes this brings:
SDL_TOUCH_MOUSEID
so it works reliably on Android and other platforms like X11SDL_HINT_MOUSE_TOUCH_EVENTS
(to control whether mouse will cause fake touch events), and removal of android-specificSDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH
such that this can now be controlled cross-platform in the same manner, not just for android/mobileSDL_HINT_ANDROID_ON_PAUSE
to control whetherSDL_PollEvent
blocks when the app goes into background or not, currently SDL_PollEvent always blocks and this is force-enabledMajor python-for-android fixes:
.java
copied out of SDL2 in our source tree is gone, only the.patch
forSDLActivity.java
for making the loading screen work is left. This should make future upgrades considerably less work since one can just bump the version inrecipes/SDL2/__init__.py
and adapt the patch as necessary and done. (right now you'd also need to copy over the new.java
files in the exact matching version and if you forgot it might crash, misbehave, or do all sorts of weird things)