kmx git

Commit	Date	Message
aa03b9d7	2016-11-22T22:14:28	The XBox One S controller sends keys outside the standard joystick button range
6558ecdb	2016-11-22T04:42:07	Added mapping for XBox One S controller firmware version 3.1.1221.0
a949882a	2016-11-21T20:35:59	cpuinfo: fix SDL_HasNEON() on older iOS devices, fixed C++ comment.
36156335	2016-11-20T21:34:54	Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain
abe92710	2016-11-20T21:29:27	Fixed warning building under mingw, patch contributed by Sylvain
eaca3958	2016-11-20T21:24:09	Fixed bug 3494 - SDL_test_fuzzer.c fails compile since r10604 Ozkan Sezer As of hg rev. 10604 (http://hg.libsdl.org/SDL/rev/4fe01fd25855), SDL_test_fuzzer.c fails to build again
4a089ca1	2016-11-20T21:18:55	Fixed bug 3486 - Can't get HINSTANCE of my window realitix SDL2 allows to create widow and to get information through SDL_SysWMinfo. But it misses something, with Vulkan, you need the HWND and HINSTANCE of the window for Win32 system. Sadly, SDL2 provides only HWND but not HINSTANCE. In some context, it can be difficult to get the HINSTANCE, indeed, I'm using pySDL2 (Python) and I can only access properties that SDL2 gives me. I have to use a dirty trick like that to get the HINSTANCE: (https://raw.githubusercontent.com/bglgwyng/pyVulkan/master/examples/win32misc.py)
eb9cc030	2016-11-19T23:27:37	Fixed two memory leaks if added game controller mapping has lower priority. Found by buildbot.
a49ac09c	2016-11-18T00:06:09	Windows: Fixed crash if using current SDL_GetWindowWMInfo() from older programs.
d05a39d0	2016-11-18T00:05:54	Wayland: Fixed file descriptor leaks if device was not initialized.
c3451262	2016-11-18T00:05:28	Emscripten: Fixed handling of deactivated mouse events. SDL_GetEventState() was called with a button state instead of an event type.
32cb3494	2016-11-17T17:03:43	cpuinfo: patched to compile for getauxval() path.
0b33a118	2016-11-17T16:10:32	cpuinfo: more patching for Android. Legacy platform targets are a pain.
a298e563	2016-11-17T16:04:00	cpuinfo: Patched to compile on Android, Linux.
e8f4b7c4	2016-11-17T16:01:59	cpuinfo: patched to compile. Nothing quite like experimentation via Buildbot! :/
74eb78dc	2016-11-17T15:57:58	cpuinfo: more work on SDL_HasNEON().
db97c3d3	2016-11-17T01:41:56	cpuinfo: silence compiler warnings on non-Intel CPU architectures.
66a36d56	2016-11-17T01:34:18	cpuinfo: disable NEON detection on Android for now. Will fix this properly soon.
5c6b2ebf	2016-11-17T01:26:56	cpuinfo: more robust ARM preprocessor checks.
35430a73	2016-11-17T01:15:16	cpuinfo: first attempt at SDL_HasNEON() implementation.
7592b40b	2016-11-16T22:49:04	cpuinfo: Removed code duplication, cached CPUID details.
6fe15d63	2016-11-16T22:09:40	Wayland: Fixed memory leak if output retrieval failed. Found by Cppcheck.
97aa5775	2016-11-16T22:08:51	Fixed empty parameter list in signatures of internal functions.
818d1d3e	2016-11-15T01:30:08	Fixed bug 1646 - Warnings from clang with -Weverything
0d24495b	2016-11-15T01:24:58	Removed unused constants Except for SDL_bmp.c where they are historically interesting and I've left them in.
009a3f5a	2016-11-15T01:14:30	Fixed bug 3490 - Build failure with --enable-video-directfb felix Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.
ab8bd3d9	2016-11-15T01:12:27	Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
c1e292fc	2016-11-13T23:09:42	Fixed build error with missing function prototype in the SDL_test_harness.h header
c2837ef6	2016-11-13T23:04:47	Fixed unresolved symbol on Visual Studio
57d01d7d	2016-11-13T22:57:41	Patch from Sylvain to fix clang warnings
acce8659	2016-11-13T10:39:04	[qtwayland] Set orientation and window flags via SDL hints
c13a077d	2016-11-13T00:09:02	Fixed bug 3488 - Random crashes (because Memory overlap in audio converters detected by Valgrind) Vitaly Novichkov Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone. Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.
37696150	2016-11-11T13:47:40	Fixed build on various platforms
77000ff8	2016-11-11T13:38:39	Fixed bug 1822 - Inconsistent renderer behaviour on rotation Sylvain 2016-11-07 08:49:34 UTC when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey. if you set a dummy colorkey, it will remove the line ... if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
23c01c18	2016-11-11T13:29:23	Fixed bug 3079 - Allow non destructive SDL_GameControllerAddMappingsFromFile x414e54 It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings. So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping. There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable. Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings. For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.
74e1dd4c	2016-11-11T13:14:00	Define _GNU_SOURCE when building SDL
302a6e62	2016-11-11T12:41:06	Fixed bug 3484 - DSP driver does not detect /dev/dsp0 Tobias Kortkamp using SDL 2.0.5 (and a repository checkout) on FreeBSD 11.0 I get this output from testaudioinfo with SDL_AUDIODRIVER=dsp: INFO: Found 8 output devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp1 INFO: 2: /dev/dsp2 INFO: 3: /dev/dsp3 INFO: 4: /dev/dsp4 INFO: 5: /dev/dsp5 INFO: 6: /dev/dsp6 INFO: 7: /dev/dsp7 INFO: INFO: Found 3 capture devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp4 INFO: 2: /dev/dsp5 INFO: This is /dev/sndstat: Installed devices: pcm0: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm1: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm2: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm3: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm4: <Realtek ALC887 (Rear Analog 7.1/2.0)> (play/rec) pcm5: <Realtek ALC887 (Front Analog)> (play/rec) default pcm6: <Realtek ALC887 (Rear Digital)> (play) pcm7: <Realtek ALC887 (Onboard Digital)> (play) No devices installed from userspace. I'd expect to find /dev/dsp0 in the output device list. It's not detected because of a a small logic error in SDL_audiodev.c (see attached patch). With the patch applied I get this which is what I'd expect: INFO: Found 9 output devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp0 INFO: 2: /dev/dsp1 INFO: 3: /dev/dsp2 INFO: 4: /dev/dsp3 INFO: 5: /dev/dsp4 INFO: 6: /dev/dsp5 INFO: 7: /dev/dsp6 INFO: 8: /dev/dsp7
160e7194	2016-11-11T04:35:06	Fixed whitespace and added code to support older game controller GUIDs
b6542ab2	2016-11-11T04:30:09	Fixed whitespace
47418f2d	2016-11-11T03:35:37	Updated Windows game controller support
79f6ba5a	2016-11-11T03:18:16	Fixed signed/unsigned comparison warnings in Visual Studio
801a9eaf	2016-11-11T04:06:00	Updated Mac OS X game controller support
0cc6207c	2016-11-10T18:53:29	Added Linux entries for the Logitech Dual Action game controller
ac74e16c	2016-11-10T17:19:34	Standardized the format of the SDL joystick GUID and added functions to retrieve the USB VID/PID from a joystick and game controller.
2898ada3	2016-11-10T12:07:34	wayland: fixed compiler warning about pipe2().
6380d5c2	2016-11-07T21:10:01	Fixed audio conversion for unsigned 16 bit data.
057bca8a	2016-11-06T15:15:32	Better fix for last point in D3D11 renderer, thanks to Nader Golbaz
40b571c9	2016-11-06T10:01:08	Fixed bug 3468 - _allshr in SDL_stdlib.c is not working properly Mark Pizzolato On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c. One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work. I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously. I reopened #2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
d7800312	2016-11-06T09:30:06	Fixed bug 3476 - round() needs _GNU_SOURCE on some old systems Ozkan Sezer On systems with old glibc, such mine with glibc-2.8, the following warning is issued and is fixed easily by defining _GNU_SOURCE: /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c: In function 'CalculateXRandRRefreshRate': /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: implicit declaration of function 'round' /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: incompatible implicit declaration of built-in function 'round'
330e2952	2016-11-06T08:47:40	Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90. Nader Golbaz Updated patch for direct3d renderers
4ed4997c	2016-11-06T08:42:46	Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90 Nader Golbaz Updated patch for direct3d renderers
d767a450	2016-11-06T08:34:27	Fixed 2942 - Wayland: Drag and Drop / Clipboard x414e54 I have implemented Drag and Drop and Clipboard support for Wayland. Drag and dropping files from nautilus to the testdropfile application seems to work and also copy and paste.
7ad3a46d	2016-11-05T21:23:17	ALSA: Fixed compile warning about unused function. Found by buildbot.
58199232	2016-11-05T21:22:58	WinRT: Corrected header file guard comment.
062ca2b2	2016-11-05T21:22:39	Removed empty statement.
6ed82130	2016-11-05T01:52:28	Fixed Windows build
a17abf10	2016-11-05T03:56:55	Also patched to compile on C89 compilers.
067f0c84	2016-11-05T03:53:59	Patched to compile on C89 compilers.
f3456e9a	2016-11-05T02:34:38	Reworked audio converter code. This no longer uses a script to generate code for every possible type conversion or resampler. This caused a bloat in binary size and and compile times. Now we use a handful of more generic functions and assume staying in the CPU cache is the most important thing anyhow. This shrinks the size of the final build (in this case: macOS X amd64, -Os to optimize for size) by 15%. When compiling on a single core, build times drop by about 15% too (although the previous cost was largely hidden by multicore builds).
0f83ae0f	2016-11-03T01:29:56	Added some debug logging to print out every event added to the SDL queue.
baadd546	2016-11-02T02:56:54	Fixed text input events with UIM Alex Baines I realized overnight that my patch probably broke text input events with UIM, and I confirmed that it does. Can't believe I overlooked that... I've been making stupid mistakes in these patches recently, sorry. Anyway, this one seems to fix it properly. Knowing my luck it probably breaks something else.
acae3ebf	2016-11-02T02:50:27	Added mapping for the PS3 controller in Bluetooth mode
d0c8bf7f	2016-11-01T10:48:59	Patch from Tapani P?lli to fix a memory leak in X11_InitKeyboard Patch uses XkbFreeKeyboard to free the memory returned by XkbGetMap. Earlier implementation called XkbFreeClientMap which frees all the maps but not data->xkb structure itself, XkbFreeKeyboard will free maps and the structure.
a1f42765	2016-11-01T10:46:47	Patch from Tapani P?lli to fix a memory leak in X11_GL_CreateContext
8eb76276	2016-11-01T17:38:05	Skip duplicate key events sent by IMEs like uim.
539afc5d	2016-11-01T10:33:44	Fixed bug 3473 - can't build on linux with an old kernel
9a8642bd	2016-11-01T10:30:46	Fixed bug 3478 - Patch Haiku to use dlopen instead of load_add_on Kai Sterker SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings. As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
88f2d16e	2016-10-28T17:00:37	Fixed compiling on older versions of ALSA
fdcac1c2	2016-10-28T16:47:06	Fixed audio data swizzling when the device channel map already matches what SDL expects
5fe98497	2016-10-28T01:28:58	Fix double events / no repeat flag on key events when built withoutibus/fcitx Uses XkbSetDetectableKeyRepeat, and falls back to forcing @im=none if it's not supported.
39ba2ab8	2016-10-22T17:53:03	Fixed NULL pointer dereference, thanks Ozkan Sezer
5b14a943	2016-10-22T11:01:55	Fixed bug 3466 - Can't build 2.0.5 on ppc64 /home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32': /home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00, ^
8a73f7e8	2016-10-19T20:42:22	Fixed bug 3461 - Implement TEXTINPUT events for Haiku Kai Sterker Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events. Attached is a patch that adds this functionality. Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.
6d67c98e	2016-10-19T20:39:12	Fixed crash on Mac OS X 10.10 and earlier
012217f0	2016-10-18T23:24:49	Fixed bug 3369 - RaspberryPI ability to specify a Dispmanx layer Albert Casals On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses. Currently, it is hardcoded to be 10000 to sit above most applications. This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.
267207ff	2016-10-18T23:12:45	Worked around a crash on Mac OS X 10.10 and earlier, thanks to Eric Wasylishen.
ae8ca7c5	2016-10-17T22:09:22	Fixed bug 3444 - Android-TV: no more handling of back button on remote ny00 Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue: If an SDL joystick is connected and opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected. If, however, the joystick was not opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem). What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code. Here is a possible solution: - Do check the return codes of "onNativePadDown/Up" as previously done. - In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should always be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.
8109b137	2016-10-17T21:47:33	Partial fix for bug 3092 - Statically link sdl2 with /MT for msvc Mike Linford I'm also having trouble statically linking SDL2 on Visual Studio 2015 with /MT. My symptom is that memcpy is being defined twice.
0eb5c976	2016-10-17T21:44:32	Fixed bug 3456 - SDL_GameControllerOpen fails if the joystick subsystem isn't initialized Philipp Wiesemann Maybe the fault is in the SDL_VIDEO_DRIVER_WINDOWS section in SDL_InitSubSystem() of "src/SDL.c". Because there only SDL_INIT_JOYSTICK is checked. The flags are adapted for SDL_INIT_GAMECONTROLLER afterwards.
5af67f49	2016-10-17T21:37:26	Fixed bug 3458 - x11: reset deadkeys in StartTextInput/StopTextInput Eric Wasylishen The patch makes StartTextInput/StopTextInput call Xutf8ResetIC ( https://www.x.org/releases/X11R7.5/doc/man/man3/XmbResetIC.3.html ) on the XIC of all SDL windows. This fixes my use case in Quakespasm (Ubuntu 16.04, system keyboard layout set to German. Type the '^' dead key, which opens Quakespasm's developer console and calls SDL_StartTextInput, then press 'e'. I expect the dead key to be ignored.) Also, here is a patch for sdl2's "checkkeys" for testing this: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2451
ba051ae7	2016-10-16T22:47:49	Linux: Added missing scancodes.
f31ce3fb	2016-10-16T22:47:37	Windows: Fixed not removing the always added hint callback on quit. This was no real problem because SDL_Quit() also calls SDL_ClearHints().
c0578f92	2016-10-16T22:46:56	Linux: Removed not needed platform info from entry in controller database.
099e8a68	2016-10-15T20:02:17	Linux: Fixed compile warnings about unused variables.
01f62736	2016-10-14T17:06:28	emscripten: check if device pixel ratio has changed
d5ddb3cb	2016-10-14T08:40:21	Fixed bug 3453 - First mouse button input after a drag and drop event is ignored Olav Sorensen After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a second time generates an event like it should. Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.
8aab39cb	2016-10-14T08:27:44	Fixed bug 3452 - Getting unicode arguments for the main entry point on Windows Simon Hug There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8. Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.
3f38bd91	2016-10-14T08:22:48	Fixed warning about redefining DECLSPEC
3663dbe8	2016-10-14T08:20:40	Fixed warning about missing field initializers in SDL_DBusContext Static variables are automatically initialized to zero.
824ecc8f	2016-10-14T08:15:39	Fixed processing mouse and keyboard events in hatari, which uses the old SDLMain.m without creating an SDLApplication instance
83cb2b63	2016-10-14T06:57:55	Fixed bug 2758 - Android issues with NDK r10c and API-21 Sylvain After a long time, I found out more clearly what was going wrong. The native libraries should be built with a "APP_PLATFORM" as low as possible. Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml So that the application never runs on a lower APP_PLATFORM than it has been built for. An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10 (If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10. And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".) to precise what happened in the initial reported test-case: Let say the "c" code contains a call to "srand()". with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()". with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()". but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()). So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10. That was the issue. The path tried to fix this by in fact always calling srand48(). SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform. It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions. Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.
f3502c3c	2016-10-14T01:04:21	Fixed building with cmake when fcitx isn't installed
8e2634eb	2016-10-14T00:51:57	Fixed divide by zero if setting integer scale without setting logical width and height
662f966c	2016-10-13T08:46:34	Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer. Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
e4af8ce9	2016-10-13T04:57:31	Fixed typo getting the drawable size
063f752e	2016-10-13T04:54:43	Fixed bug 3328 - Race condition in Wayland_VideoInit Robert Folland When running this little test program with SDL2 on Wayland it often crashes in SDL_Init. From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0. By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed. I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect(). Here is the test program (just a loop of init and quit), and a backtrace from gdb: #include <cstdio> #include <stdlib.h> #include <SDL2/SDL.h> #include <unistd.h> #include <iostream> int main(int argc, char **argv) { int count = atoi(argv[1]); for (int i = 0; i < count; i++) { std::cout << "Init " << i << std::endl; if (SDL_Init(SDL_INIT_VIDEO) < 0) { SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't initialize SDL: %s\n", SDL_GetError()); return 1; } std::cout << "Quit" << std::endl; SDL_Quit(); } return 0; } Init 12 Quit Init 13 Program received signal SIGSEGV, Segmentation fault. xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 156 ctx->refcnt++; (gdb) bt #0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 #1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65 #2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>, buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090, format=<optimized out>, flags=<optimized out>) at src/keymap.c:191 #3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269 #4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6 #5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6 #6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20, opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949 #7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274 #8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420 #9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662 #10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085 #11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302 #12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513 #13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173 #14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13 (gdb)
f94bd057	2016-10-13T04:53:01	Fixed bug 3451 - Raspberry Pi Raspbian SDL_assert triggered sometimes at RPI_WarpMouseGlobal Eric wing Sometimes an SDL_assert triggers at RPI_WarpMouseGlobal src/video/raspberry/SDL_rpimouse.c:232 'update'. It doesn't always reproduce, but it seems to happen when you really bog down the system and the event loop can't update for awhile. The first time I hit this, I wasn't even using the mouse. I don't call any warp mouse functions either. I can usually reproduce with a simple program that runs an expensive blocking CPU series of functions which blocks the main loop until complete (can be up to 10 seconds). Sometimes this assertion gets triggered after that. I'm not sure if they are related or coincidental. Disabling the SDL_asserts when compiling SDL will avoid this problem. I actually haven't seen any problems with the mouse when I do this. On a Raspberry Pi 2 running Raspbian Jessie.
3f167a5a	2016-10-13T02:19:23	Added support for the PS4 Slim controller, model CUH-ZCT2U
741aaf4c	2016-10-12T22:34:54	Added a note on how to allow non-root applications to increase their thread priority on Linux
62310c6b	2016-10-12T22:25:19	Work-around for a hang when USB devices are unplugged, contributed by James Zipperer

aa03b9d7

2016-11-22T22:14:28

The XBox One S controller sends keys outside the standard joystick button range

6558ecdb

2016-11-22T04:42:07

Added mapping for XBox One S controller firmware version 3.1.1221.0

a949882a

2016-11-21T20:35:59

cpuinfo: fix SDL_HasNEON() on older iOS devices, fixed C++ comment.

36156335

2016-11-20T21:34:54

Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain

abe92710

2016-11-20T21:29:27

Fixed warning building under mingw, patch contributed by Sylvain

eaca3958

2016-11-20T21:24:09

Fixed bug 3494 - SDL_test_fuzzer.c fails compile since r10604 Ozkan Sezer As of hg rev. 10604 (http://hg.libsdl.org/SDL/rev/4fe01fd25855), SDL_test_fuzzer.c fails to build again

4a089ca1

2016-11-20T21:18:55

Fixed bug 3486 - Can't get HINSTANCE of my window realitix SDL2 allows to create widow and to get information through SDL_SysWMinfo. But it misses something, with Vulkan, you need the HWND and HINSTANCE of the window for Win32 system. Sadly, SDL2 provides only HWND but not HINSTANCE. In some context, it can be difficult to get the HINSTANCE, indeed, I'm using pySDL2 (Python) and I can only access properties that SDL2 gives me. I have to use a dirty trick like that to get the HINSTANCE: (https://raw.githubusercontent.com/bglgwyng/pyVulkan/master/examples/win32misc.py)

eb9cc030

2016-11-19T23:27:37

Fixed two memory leaks if added game controller mapping has lower priority. Found by buildbot.

a49ac09c

2016-11-18T00:06:09

Windows: Fixed crash if using current SDL_GetWindowWMInfo() from older programs.

d05a39d0

2016-11-18T00:05:54

Wayland: Fixed file descriptor leaks if device was not initialized.

c3451262

2016-11-18T00:05:28

Emscripten: Fixed handling of deactivated mouse events. SDL_GetEventState() was called with a button state instead of an event type.

32cb3494

2016-11-17T17:03:43

cpuinfo: patched to compile for getauxval() path.

0b33a118

2016-11-17T16:10:32

cpuinfo: more patching for Android. Legacy platform targets are a pain.

a298e563

2016-11-17T16:04:00

cpuinfo: Patched to compile on Android, Linux.

e8f4b7c4

2016-11-17T16:01:59

cpuinfo: patched to compile. Nothing quite like experimentation via Buildbot! :/

74eb78dc

2016-11-17T15:57:58

cpuinfo: more work on SDL_HasNEON().

db97c3d3

2016-11-17T01:41:56

cpuinfo: silence compiler warnings on non-Intel CPU architectures.

66a36d56

2016-11-17T01:34:18

cpuinfo: disable NEON detection on Android for now. Will fix this properly soon.

5c6b2ebf

2016-11-17T01:26:56

cpuinfo: more robust ARM preprocessor checks.

35430a73

2016-11-17T01:15:16

cpuinfo: first attempt at SDL_HasNEON() implementation.

7592b40b

2016-11-16T22:49:04

cpuinfo: Removed code duplication, cached CPUID details.

6fe15d63

2016-11-16T22:09:40

Wayland: Fixed memory leak if output retrieval failed. Found by Cppcheck.

97aa5775

2016-11-16T22:08:51

Fixed empty parameter list in signatures of internal functions.

818d1d3e

2016-11-15T01:30:08

Fixed bug 1646 - Warnings from clang with -Weverything

0d24495b

2016-11-15T01:24:58

Removed unused constants Except for SDL_bmp.c where they are historically interesting and I've left them in.

009a3f5a

2016-11-15T01:14:30

Fixed bug 3490 - Build failure with --enable-video-directfb felix Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.

ab8bd3d9

2016-11-15T01:12:27

Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.

c1e292fc

2016-11-13T23:09:42

Fixed build error with missing function prototype in the SDL_test_harness.h header

c2837ef6

2016-11-13T23:04:47

Fixed unresolved symbol on Visual Studio

57d01d7d

2016-11-13T22:57:41

Patch from Sylvain to fix clang warnings

acce8659

2016-11-13T10:39:04

[qtwayland] Set orientation and window flags via SDL hints

c13a077d

2016-11-13T00:09:02

Fixed bug 3488 - Random crashes (because Memory overlap in audio converters detected by Valgrind) Vitaly Novichkov Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone. Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.

37696150

2016-11-11T13:47:40

Fixed build on various platforms

77000ff8

2016-11-11T13:38:39

Fixed bug 1822 - Inconsistent renderer behaviour on rotation Sylvain 2016-11-07 08:49:34 UTC when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey. if you set a dummy colorkey, it will remove the line ... if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...

23c01c18

2016-11-11T13:29:23

Fixed bug 3079 - Allow non destructive SDL_GameControllerAddMappingsFromFile x414e54 It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings. So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping. There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable. Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings. For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.

74e1dd4c

2016-11-11T13:14:00

Define _GNU_SOURCE when building SDL

302a6e62

2016-11-11T12:41:06

Fixed bug 3484 - DSP driver does not detect /dev/dsp0 Tobias Kortkamp using SDL 2.0.5 (and a repository checkout) on FreeBSD 11.0 I get this output from testaudioinfo with SDL_AUDIODRIVER=dsp: INFO: Found 8 output devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp1 INFO: 2: /dev/dsp2 INFO: 3: /dev/dsp3 INFO: 4: /dev/dsp4 INFO: 5: /dev/dsp5 INFO: 6: /dev/dsp6 INFO: 7: /dev/dsp7 INFO: INFO: Found 3 capture devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp4 INFO: 2: /dev/dsp5 INFO: This is /dev/sndstat: Installed devices: pcm0: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm1: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm2: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm3: <NVIDIA (0x0040) (HDMI/DP 8ch)> (play) pcm4: <Realtek ALC887 (Rear Analog 7.1/2.0)> (play/rec) pcm5: <Realtek ALC887 (Front Analog)> (play/rec) default pcm6: <Realtek ALC887 (Rear Digital)> (play) pcm7: <Realtek ALC887 (Onboard Digital)> (play) No devices installed from userspace. I'd expect to find /dev/dsp0 in the output device list. It's not detected because of a a small logic error in SDL_audiodev.c (see attached patch). With the patch applied I get this which is what I'd expect: INFO: Found 9 output devices: INFO: 0: /dev/dsp INFO: 1: /dev/dsp0 INFO: 2: /dev/dsp1 INFO: 3: /dev/dsp2 INFO: 4: /dev/dsp3 INFO: 5: /dev/dsp4 INFO: 6: /dev/dsp5 INFO: 7: /dev/dsp6 INFO: 8: /dev/dsp7

160e7194

2016-11-11T04:35:06

Fixed whitespace and added code to support older game controller GUIDs

b6542ab2

2016-11-11T04:30:09

Fixed whitespace

47418f2d

2016-11-11T03:35:37

Updated Windows game controller support

79f6ba5a

2016-11-11T03:18:16

Fixed signed/unsigned comparison warnings in Visual Studio

801a9eaf

2016-11-11T04:06:00

Updated Mac OS X game controller support

0cc6207c

2016-11-10T18:53:29

Added Linux entries for the Logitech Dual Action game controller

ac74e16c

2016-11-10T17:19:34

Standardized the format of the SDL joystick GUID and added functions to retrieve the USB VID/PID from a joystick and game controller.

2898ada3

2016-11-10T12:07:34

wayland: fixed compiler warning about pipe2().

6380d5c2

2016-11-07T21:10:01

Fixed audio conversion for unsigned 16 bit data.

057bca8a

2016-11-06T15:15:32

Better fix for last point in D3D11 renderer, thanks to Nader Golbaz

40b571c9

2016-11-06T10:01:08

Fixed bug 3468 - _allshr in SDL_stdlib.c is not working properly Mark Pizzolato On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c. One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work. I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously. I reopened #2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.

d7800312

2016-11-06T09:30:06

Fixed bug 3476 - round() needs _GNU_SOURCE on some old systems Ozkan Sezer On systems with old glibc, such mine with glibc-2.8, the following warning is issued and is fixed easily by defining _GNU_SOURCE: /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c: In function 'CalculateXRandRRefreshRate': /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: implicit declaration of function 'round' /home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: incompatible implicit declaration of built-in function 'round'

330e2952

2016-11-06T08:47:40

Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90. Nader Golbaz Updated patch for direct3d renderers

4ed4997c

2016-11-06T08:42:46

Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90 Nader Golbaz Updated patch for direct3d renderers

d767a450

2016-11-06T08:34:27

Fixed 2942 - Wayland: Drag and Drop / Clipboard x414e54 I have implemented Drag and Drop and Clipboard support for Wayland. Drag and dropping files from nautilus to the testdropfile application seems to work and also copy and paste.

7ad3a46d

2016-11-05T21:23:17

ALSA: Fixed compile warning about unused function. Found by buildbot.

58199232

2016-11-05T21:22:58

WinRT: Corrected header file guard comment.

062ca2b2

2016-11-05T21:22:39

Removed empty statement.

6ed82130

2016-11-05T01:52:28

Fixed Windows build

a17abf10

2016-11-05T03:56:55

Also patched to compile on C89 compilers.

067f0c84

2016-11-05T03:53:59

Patched to compile on C89 compilers.

f3456e9a

2016-11-05T02:34:38

Reworked audio converter code. This no longer uses a script to generate code for every possible type conversion or resampler. This caused a bloat in binary size and and compile times. Now we use a handful of more generic functions and assume staying in the CPU cache is the most important thing anyhow. This shrinks the size of the final build (in this case: macOS X amd64, -Os to optimize for size) by 15%. When compiling on a single core, build times drop by about 15% too (although the previous cost was largely hidden by multicore builds).

0f83ae0f

2016-11-03T01:29:56

Added some debug logging to print out every event added to the SDL queue.

baadd546

2016-11-02T02:56:54

Fixed text input events with UIM Alex Baines I realized overnight that my patch probably broke text input events with UIM, and I confirmed that it does. Can't believe I overlooked that... I've been making stupid mistakes in these patches recently, sorry. Anyway, *this* one seems to fix it properly. Knowing my luck it probably breaks something else.

acae3ebf

2016-11-02T02:50:27

Added mapping for the PS3 controller in Bluetooth mode

d0c8bf7f

2016-11-01T10:48:59

Patch from Tapani P?lli to fix a memory leak in X11_InitKeyboard Patch uses XkbFreeKeyboard to free the memory returned by XkbGetMap. Earlier implementation called XkbFreeClientMap which frees all the maps but not data->xkb structure itself, XkbFreeKeyboard will free maps and the structure.

a1f42765

2016-11-01T10:46:47

Patch from Tapani P?lli to fix a memory leak in X11_GL_CreateContext

8eb76276

2016-11-01T17:38:05

Skip duplicate key events sent by IMEs like uim.

539afc5d

2016-11-01T10:33:44

Fixed bug 3473 - can't build on linux with an old kernel

9a8642bd

2016-11-01T10:30:46

Fixed bug 3478 - Patch Haiku to use dlopen instead of load_add_on Kai Sterker SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings. As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.

88f2d16e

2016-10-28T17:00:37

Fixed compiling on older versions of ALSA

fdcac1c2

2016-10-28T16:47:06

Fixed audio data swizzling when the device channel map already matches what SDL expects

5fe98497

2016-10-28T01:28:58

Fix double events / no repeat flag on key events when built withoutibus/fcitx Uses XkbSetDetectableKeyRepeat, and falls back to forcing @im=none if it's not supported.

39ba2ab8

2016-10-22T17:53:03

Fixed NULL pointer dereference, thanks Ozkan Sezer

5b14a943

2016-10-22T11:01:55

Fixed bug 3466 - Can't build 2.0.5 on ppc64 /home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32': /home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00, ^

8a73f7e8

2016-10-19T20:42:22

Fixed bug 3461 - Implement TEXTINPUT events for Haiku Kai Sterker Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events. Attached is a patch that adds this functionality. Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.

6d67c98e

2016-10-19T20:39:12

Fixed crash on Mac OS X 10.10 and earlier

012217f0

2016-10-18T23:24:49

Fixed bug 3369 - RaspberryPI ability to specify a Dispmanx layer Albert Casals On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses. Currently, it is hardcoded to be 10000 to sit above most applications. This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.

267207ff

2016-10-18T23:12:45

Worked around a crash on Mac OS X 10.10 and earlier, thanks to Eric Wasylishen.

ae8ca7c5

2016-10-17T22:09:22

Fixed bug 3444 - Android-TV: no more handling of back button on remote ny00 Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue: If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected. If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem). What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code. Here is a possible solution: - Do check the return codes of "onNativePadDown/Up" as previously done. - In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.

8109b137

2016-10-17T21:47:33

Partial fix for bug 3092 - Statically link sdl2 with /MT for msvc Mike Linford I'm also having trouble statically linking SDL2 on Visual Studio 2015 with /MT. My symptom is that memcpy is being defined twice.

0eb5c976

2016-10-17T21:44:32

Fixed bug 3456 - SDL_GameControllerOpen fails if the joystick subsystem isn't initialized Philipp Wiesemann Maybe the fault is in the SDL_VIDEO_DRIVER_WINDOWS section in SDL_InitSubSystem() of "src/SDL.c". Because there only SDL_INIT_JOYSTICK is checked. The flags are adapted for SDL_INIT_GAMECONTROLLER afterwards.

5af67f49

2016-10-17T21:37:26

Fixed bug 3458 - x11: reset deadkeys in StartTextInput/StopTextInput Eric Wasylishen The patch makes StartTextInput/StopTextInput call Xutf8ResetIC ( https://www.x.org/releases/X11R7.5/doc/man/man3/XmbResetIC.3.html ) on the XIC of all SDL windows. This fixes my use case in Quakespasm (Ubuntu 16.04, system keyboard layout set to German. Type the '^' dead key, which opens Quakespasm's developer console and calls SDL_StartTextInput, then press 'e'. I expect the dead key to be ignored.) Also, here is a patch for sdl2's "checkkeys" for testing this: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2451

ba051ae7

2016-10-16T22:47:49

Linux: Added missing scancodes.

f31ce3fb

2016-10-16T22:47:37

Windows: Fixed not removing the always added hint callback on quit. This was no real problem because SDL_Quit() also calls SDL_ClearHints().

c0578f92

2016-10-16T22:46:56

Linux: Removed not needed platform info from entry in controller database.

099e8a68

2016-10-15T20:02:17

Linux: Fixed compile warnings about unused variables.

01f62736

2016-10-14T17:06:28

emscripten: check if device pixel ratio has changed

d5ddb3cb

2016-10-14T08:40:21

Fixed bug 3453 - First mouse button input after a drag and drop event is ignored Olav Sorensen After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should. Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.

8aab39cb

2016-10-14T08:27:44

Fixed bug 3452 - Getting unicode arguments for the main entry point on Windows Simon Hug There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8. Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.

3f38bd91

2016-10-14T08:22:48

Fixed warning about redefining DECLSPEC

3663dbe8

2016-10-14T08:20:40

Fixed warning about missing field initializers in SDL_DBusContext Static variables are automatically initialized to zero.

824ecc8f

2016-10-14T08:15:39

Fixed processing mouse and keyboard events in hatari, which uses the old SDLMain.m without creating an SDLApplication instance

83cb2b63

2016-10-14T06:57:55

Fixed bug 2758 - Android issues with NDK r10c and API-21 Sylvain After a long time, I found out more clearly what was going wrong. The native libraries should be built with a "APP_PLATFORM" as low as possible. Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml So that the application never runs on a lower APP_PLATFORM than it has been built for. An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10 (If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10. And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".) to precise what happened in the initial reported test-case: Let say the "c" code contains a call to "srand()". with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()". with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()". but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()). So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10. That was the issue. The path tried to fix this by in fact always calling srand48(). SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform. It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions. Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.

f3502c3c

2016-10-14T01:04:21

Fixed building with cmake when fcitx isn't installed

8e2634eb

2016-10-14T00:51:57

Fixed divide by zero if setting integer scale without setting logical width and height

662f966c

2016-10-13T08:46:34

Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer. Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.

e4af8ce9

2016-10-13T04:57:31

Fixed typo getting the drawable size

063f752e

2016-10-13T04:54:43

Fixed bug 3328 - Race condition in Wayland_VideoInit Robert Folland When running this little test program with SDL2 on Wayland it often crashes in SDL_Init. From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0. By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed. I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect(). Here is the test program (just a loop of init and quit), and a backtrace from gdb: #include <cstdio> #include <stdlib.h> #include <SDL2/SDL.h> #include <unistd.h> #include <iostream> int main(int argc, char **argv) { int count = atoi(argv[1]); for (int i = 0; i < count; i++) { std::cout << "Init " << i << std::endl; if (SDL_Init(SDL_INIT_VIDEO) < 0) { SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't initialize SDL: %s\n", SDL_GetError()); return 1; } std::cout << "Quit" << std::endl; SDL_Quit(); } return 0; } Init 12 Quit Init 13 Program received signal SIGSEGV, Segmentation fault. xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 156 ctx->refcnt++; (gdb) bt #0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 #1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65 #2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>, buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090, format=<optimized out>, flags=<optimized out>) at src/keymap.c:191 #3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269 #4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6 #5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6 #6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20, opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949 #7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274 #8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420 #9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662 #10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085 #11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302 #12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513 #13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173 #14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13 (gdb)

f94bd057

2016-10-13T04:53:01

Fixed bug 3451 - Raspberry Pi Raspbian SDL_assert triggered sometimes at RPI_WarpMouseGlobal Eric wing Sometimes an SDL_assert triggers at RPI_WarpMouseGlobal src/video/raspberry/SDL_rpimouse.c:232 'update'. It doesn't always reproduce, but it seems to happen when you really bog down the system and the event loop can't update for awhile. The first time I hit this, I wasn't even using the mouse. I don't call any warp mouse functions either. I can usually reproduce with a simple program that runs an expensive blocking CPU series of functions which blocks the main loop until complete (can be up to 10 seconds). Sometimes this assertion gets triggered after that. I'm not sure if they are related or coincidental. Disabling the SDL_asserts when compiling SDL will avoid this problem. I actually haven't seen any problems with the mouse when I do this. On a Raspberry Pi 2 running Raspbian Jessie.

3f167a5a

2016-10-13T02:19:23

Added support for the PS4 Slim controller, model CUH-ZCT2U

741aaf4c

2016-10-12T22:34:54

Added a note on how to allow non-root applications to increase their thread priority on Linux

62310c6b

2016-10-12T22:25:19

Work-around for a hang when USB devices are unplugged, contributed by James Zipperer

kc3-lang/SDL/src

src

Log