Wed, 17 Jun 2015 00:07:45 -0700 Partial fix for bug 2758 - Android issues with NDK r10c and API-21
Sam Lantinga <slouken@libsdl.org> [Wed, 17 Jun 2015 00:07:45 -0700] rev 9752
Partial fix for bug 2758 - Android issues with NDK r10c and API-21 Sylvain When using API 21 and running on an old device (android < 5.0 ?) some function are missing. functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand. Very few modifications on SDL to get this working : on SDL ====== Undefine android configuration : HAVE_SIGNAL HAVE_SIGACTION HAVE_ATOF In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset". Android.mk: remove the compilation of "test" directory because it contains a few rand/srand calls Also, there are more discussions about this in internet : https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfE http://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand
Wed, 17 Jun 2015 00:00:53 -0700 Fixed bug 2948 - [Android] Arrow keys from external keyboard are not received
Sam Lantinga <slouken@libsdl.org> [Wed, 17 Jun 2015 00:00:53 -0700] rev 9751
Fixed bug 2948 - [Android] Arrow keys from external keyboard are not received Sylvain http://developer.android.com/reference/android/view/InputDevice.html int SOURCE_CLASS_JOYSTICK Constant Value: 16 (0x00000010) int SOURCE_JOYSTICK Constant Value: 16777232 (0x01000010) int SOURCE_KEYBOARD Constant Value: 257 (0x00000101) int SOURCE_GAMEPAD Constant Value: 1025 (0x00000401) int SOURCE_DPAD Constant Value: 513 (0x00000201) I have an a PC keyboard that I connect to an android device. The issue is that "arrow" keys gets lost. More explanation: This device gets detected twice by the java "pollInputDevices()" both as SOURCE_KEYBOARD and as a composite (0x1000311 == SOURCE_JOYSTICK | SOURCE_KEYBOARD | SOURCE_DPAD). Because of being a SOURCE_CLASS_JOYSTICK, only the second entry is registered, and I opened it. When I press one arrow key, the java method "onKey(...)" is called. The Source "event.getSource()" is "SOURCE_KEYBOARD", so it enters this conditions : if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 || (event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) { And then, it enters : SDLActivity.onNativePadDown() (native code in "SDL_sysjoystick.c") Since the "arrows" are viewed as "D-PAD", it gets translated : int button = keycode_to_SDL(keycode); But the android-java "event.getDeviceId()" is wrong: this is the one from the Keyboard, and not the one from the Joystick that I have opened. So I don't get them through the Joystick interface. And since, the keycode has been translated, it returns 0 and assume it was consumed. So I lost the key in the function "Android_OnPadDown()" Notice, It won't happen with other normal "letters" keys because they does not get translated by "keycode_to_SDL", so "Android_OnPadDown()" returns -1. And then java code send the keys to "SDLActivity.onNativeKeyDown()". Possible patch on "Android_OnPadDown" and also "Android_OnPadUp" (and maybe other functons): 85 int 186 Android_OnPadDown(int device_id, int keycode) 187 { 188 SDL_joylist_item *item; 189 int button = keycode_to_SDL(keycode); 190 if (button >= 0) { 191 item = JoystickByDeviceId(device_id); 192 if (item && item->joystick) { 193 SDL_PrivateJoystickButton(item->joystick, button , SDL_PRESSED); 194 } + else return -1; 195 return 0; 196 } 197 198 return -1; 199 } It would allow the java caller function to send the key to "SDLActivity.onNativeKeyDown();" Another solution, would be to replace: if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 || (event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) { by if ( (event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0) Because only "SOURCE_CLASS_JOYSTICK" devices are registered/opened.
Tue, 16 Jun 2015 23:58:09 -0700 Fixed bug 2949 - [Android] Virtual DPAD remote not registered
Sam Lantinga <slouken@libsdl.org> [Tue, 16 Jun 2015 23:58:09 -0700] rev 9750
Fixed bug 2949 - [Android] Virtual DPAD remote not registered Sylvain I have an android device to which I try to connect the google virtual remote application. https://play.google.com/store/apps/details?id=com.google.android.tv.remote The java method "pollInputDevices()" detects it as an input source 0x701 which is (SOURCE_KEYBOARD | SOURCE_GAMEPAD | SOURCE_DPAD). It it not added because it does not AND-bitwise with "SOURCE_CLASS_JOYSTICK". It's only a virtual DPAD and it works when checking also with SOURCE_CLASS_BUTTON
Tue, 16 Jun 2015 22:16:35 -0700 Fixed bug 2774 - Android: screen distorted in Landscape after background/foreground
Sam Lantinga <slouken@libsdl.org> [Tue, 16 Jun 2015 22:16:35 -0700] rev 9749
Fixed bug 2774 - Android: screen distorted in Landscape after background/foreground Sylvain With a Landscape application. Going to background with Home Key, then foreground. The screen is distorted. This has been reported by Samsung. It happens on S5 and Samsung Alpha, see the video attached. I have captured the following logcat: V/SDL (20549): onResume() V/SDL (20549): surfaceCreated() V/SDL (20549): surfaceChanged() V/SDL (20549): pixel format RGB_565 V/SDL (20549): Window size:1920x1080 I/SDL (20549): SDL_Android_Init() I/SDL (20549): SDL_Android_Init() finished! V/SDL (20549): SDL audio: opening device V/SDL (20549): SDL audio: wanted stereo 16-bit 22.05kHz, 256 frames buffer V/SDL (20549): SDL audio: got stereo 16-bit 22.05kHz, 1764 frames buffer V/SDL (20549): onWindowFocusChanged(): true V/SDL (20549): onWindowFocusChanged(): false V/SDL (20549): onPause() V/SDL (20549): nativePause() V/SDL (20549): surfaceDestroyed() Background / Foreground V/SDL (20549): onResume() V/SDL (20549): surfaceCreated() V/SDL (20549): surfaceChanged() V/SDL (20549): pixel format RGB_565 V/SDL (20549): Window size:1080x1920 V/SDL (20549): surfaceChanged() V/SDL (20549): pixel format RGB_565 V/SDL (20549): Window size:1920x1080 V/SDL (20549): onWindowFocusChanged(): true V/SDL (20549): nativeResume() This seems to be related to the fact that I have in "AndroidManifest.xml": android:configChanges="..." Because of the fields: "orientation" and also "screenSize". I have looked for another way to solve the issue. Discarding the "surfaceChanged" call, based on the "requestedOrientation" and the new Orientation. It seems to be better. On my failing test case, the first "surfaceChanged()" is discarded. Sometimes the "focusChanged()" might appear between the two "surfaceChanged()", while the surface is not yet ready. Thus, discarding also the "nativeResume()". So, for robustness, a call to "nativeResume()" is added at the end of "surfaceChanged()". Some update: 1/ First I tried, to discard the surface using the current orientation (rather than width / heigh). -> that solve the issue sometimes, but not always. 2/ Samsung Certification now accepts my application that were previously failing. 3/ I personally now owns a Samsung S5, and was able to solve the issue on my side. 4/ I now use the patch and get no complaints from my users. (but I admit, nobody seemed to be complaining before neither...). 5/ I have added a v2 because of a new smart-phone called "Black Berry Passport" that has a square screen of 1440x1440. This screen has a "status bar" so the resolution is in fact : 1440x1308. (as reported by "surfaceChanged"). Problem is: the portrait resolution is in fact a Landscape! So the "v1" patch is always discarding the "surface" of BlackBerry Passport. Which is terribly bad. Hence, I added the "v2" patch not to discard the surface when aspect ratio is < 1.20. (BB 1440/1308 is : 1.1009). Which seems fair.
Tue, 16 Jun 2015 20:28:21 +0200 Moved entry in WhatsNew.txt because it was already in 2.0.0 for Android and iOS.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Tue, 16 Jun 2015 20:28:21 +0200] rev 9748
Moved entry in WhatsNew.txt because it was already in 2.0.0 for Android and iOS.
Tue, 16 Jun 2015 20:27:01 +0200 Fixed comment in test program.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Tue, 16 Jun 2015 20:27:01 +0200] rev 9747
Fixed comment in test program.
Tue, 16 Jun 2015 20:25:53 +0200 Excluded SDL_egl.h from doxygen input.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Tue, 16 Jun 2015 20:25:53 +0200] rev 9746
Excluded SDL_egl.h from doxygen input.
Mon, 15 Jun 2015 23:44:08 -0700 Fixed bug 3015 - grab mouse inconsistent state
Sam Lantinga <slouken@libsdl.org> [Mon, 15 Jun 2015 23:44:08 -0700] rev 9745
Fixed bug 3015 - grab mouse inconsistent state Martin Gerhardy Not sure - but I think there might be a logic flaw in SDL_SetWindowGrab. The problem here is that this modifies the window flags and e.g. sets SDL_WINDOW_INPUT_GRABBED - but the _this->grabbed_window pointer is not yet set. Then in SDL_UpdateWindowGrab the _this->grabbed_window pointer is only set if the function pointer _this->SetWindowGrab is not NULL. But if this is NULL, the _this->grabbed_window pointer is never set, but every future call to any of the grab functions include an assert for: SDL_assert(!_this->grabbed_window || ((_this->grabbed_window->flags & SDL_WINDOW_INPUT_GRABBED) != 0)); That means the first call works, the second always fails and triggers the assert.
Mon, 15 Jun 2015 20:24:51 -0700 Implement repositioning the OS-rendered IME with SDL_SetTextInputRect on Windows.
Colby Klein <shakesoda@gmail.com> [Mon, 15 Jun 2015 20:24:51 -0700] rev 9744
Implement repositioning the OS-rendered IME with SDL_SetTextInputRect on Windows.
Tue, 16 Jun 2015 00:57:45 -0400 Haptic/Linux: Keep track of device numbers properly to track duplicates.
Ryan C. Gordon <icculus@icculus.org> [Tue, 16 Jun 2015 00:57:45 -0400] rev 9743
Haptic/Linux: Keep track of device numbers properly to track duplicates. Fixes Bugzilla #3014.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 tip