kmx git

Commit	Date	Message
2da830a9	2017-08-13T21:15:44	Fixed bug 3741 - more compatible initializers for arrays Ozkan Sezer An array defined like int xPositions[] = {-1, 0, 1, w-1, w, w+1 }; errors with Open Watcom: it strictly wants constants. Small patch like below makes things more compatible.
93a520b3	2017-08-13T21:12:14	Fixed bug 3605 - Software renderer no longer renders after Android screen orientation change Sylvain This still happens with the current trunk version. (software renderer of testdrawchessboard.c) When there is a rotation, the window size changed and the internal surface is marked as "surface_valid == SDL_FALSE". And all further call fails. SDL_video.c : 2478 void 2479 SDL_OnWindowResized(SDL_Window * window) 2480 { 2481 window->surface_valid = SDL_FALSE; 2482 SDL_SendWindowEvent(window, SDL_WINDOWEVENT_SIZE_CHANGED, window->w, window->h); 2483 } some error set to : 2233 return SDL_SetError("Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface"); So, this seems to be the behavior of the API ... In the loop() function of testdrawchessboard.c, we can recreate the surface/renderer : 65 if (e.type == SDL_WINDOWEVENT) 66 { 67 if (e.window.event == SDL_WINDOWEVENT_SIZE_CHANGED) 68 { 69 surface = SDL_GetWindowSurface(window); 70 renderer = SDL_CreateSoftwareRenderer(surface); 71 } 72 /* Clear the rendering surface with the specified color */ 73 SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF); 74 SDL_RenderClear(renderer); 75 } And it displays correctly.
3cae0c38	2017-08-13T21:09:00	Fixed bug 3746 - remove SDLCALL attribute from SDL_BlitFunc() funcptr Ozkan Sezer The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr. As far as I can see, *SDL_BlitFunc() is completely internal to SDL with no specific calling convention requirements. The actual functions assigned to SDL_BlitFunc seem to not have any calling conventions specified. So, easy solution is simply removing the strict calling convention from the type.
ca5c3048	2017-08-13T21:06:52	Fixed bug 3744 - missing SDLCALL in several functions Ozkan Sezer The attached patch adds missing SDLCALL to several functions, so that they properly match the headers as intended.
e54eede2	2017-08-13T21:05:15	Provide the correct state of the on-screen keyboard to the API (patch from Sylvain)
6ee66139	2017-08-13T20:55:59	Fixed bug 3235 - Make the Android window creation similar to iOS' window creation Sylvain Here's a patch. It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window. setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass. Some artefact observed : surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.
6ef1a25d	2017-08-13T20:51:08	Fixed bug 3751 - DirectFB linux_input disabled by default Clayton Craft linux_input module is disabled by default, despite the comments in source code that it is otherwise: src/video/directfb/SDL_DirectFB_video.c: devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0); /* default: on / src/video/directfb/SDL_DirectFB_video.h: #define DFBENV_USE_LINUX_INPUT "SDL_DIRECTFB_LINUX_INPUT" / Default: on */ When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!
ddeaa601	2017-08-13T20:42:41	Fixed bug 3299 - DirectInput: Incorrect joystick mapping when attaching new joysticks Jimb Esser Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput. I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)). The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.
ea9bc659	2017-08-13T20:39:00	Added check for XBOX in addition to Xbox and X-Box
78865eff	2017-08-13T20:38:06	Fixed compiler warning
f1829d95	2017-08-13T20:37:49	Added SDL_wcscmp()
af9ec8f6	2017-08-13T20:13:11	Fixed copy-paste error, thanks Alen!
df2d2994	2017-08-13T18:12:06	Fixed bug 2812 - Make libSDL2main.a usable on Android via a dummy symbol Jonas Kulla This eliminates the need to manually compile in SDL_main_android.c. Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking. I don't know how the nkd-build process works, but unless it was for some reason linking libSDL2main.a it should be unaffected.
e9772259	2017-08-13T17:59:59	Fixed bug 2839 - No way to create pre-built libraries for Android Mark Callow README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries. Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module. Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.
c87e1d52	2017-08-13T14:15:52	Fixed bug 2841 - Hint to set resource id for window icon Alexey Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
18cceb5c	2017-08-13T01:00:01	x11: Patched to compile.
0a1b905b	2017-08-13T00:58:23	x11: Fix message box titles with Unicode chars on some window managers. Fixes Bugzilla #2971.
bfd5a134	2017-08-12T20:25:49	Fixed bug 2931 - Large relative mouse motion jumps when using touch input
b2e2bcc2	2017-08-12T20:21:34	Added test debug logs for additional event types
9be597a0	2017-08-12T22:16:04	iOS: Fix app orientation when creating a landscape fullscreen window with the device currently in portrait orientation.
059d9e46	2017-08-12T17:41:59	Fixed bug 2950 - wrong axes values are set on joystick initialization Edward Rudd Device: Logitech Rumble Gamepad F510 in Xinput mode. Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time. This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers. Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect. Here is my current workaround in the game I'm working on porting.. SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1"); SDL_GameController* gamepad = SDL_GameControllerOpen(index); SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
7bab2913	2017-08-12T17:01:14	Fixed Windows build
05facb3d	2017-08-12T16:59:00	Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently Edmund Horner When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels. In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected. I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
d226594f	2017-08-12T16:48:46	Workaround for bug 3049 - SDL_Init(SDL_INIT_VIDEO) - XDM authorization key matches an existing client! malferit Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console: XDM authorization key matches an existing client! I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config: DisplayManagerauthName: MIT-MAGIC-COOKIE-1 I don't think an end user needs to know that... But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C. I run ldd to the two generated applications: Application in C: linux-gate.so.1 (0xffffe000) libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000) libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000) libc.so.6 => /lib/libc.so.6 (0xb74e2000) libm.so.6 => /lib/libm.so.6 (0xb74a0000) libdl.so.2 => /lib/libdl.so.2 (0xb749a000) librt.so.1 => /lib/librt.so.1 (0xb7491000) /lib/ld-linux.so.2 (0xb77b3000) Application compiled with Freepascal: linux-gate.so.1 (0xffffe000) libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000) libc.so.6 => /lib/libc.so.6 (0xb7367000) libm.so.6 => /lib/libm.so.6 (0xb7325000) libdl.so.2 => /lib/libdl.so.2 (0xb731f000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000) librt.so.1 => /lib/librt.so.1 (0xb72fc000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000) /lib/ld-linux.so.2 (0xb7755000) It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp . Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well. So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help. Hi, some tests: 1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11. 2. Enabled XDM. Added 'DisplayManagerauthName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11. 3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.
45cec28b	2017-08-12T16:44:00	Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c Coriiander There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c". When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.
e3f3a757	2017-08-12T16:02:33	Fixed bug 3158 - SDL display window scrambled over VNC Witek Jachimczyk I'm using SDL to develop a video viewer for MATLAB. The window is scrambled while using thightVNC with its default mode of RGB656. SDL does not correctly recognize the pixel mode. I found a solution for this problem. The solution involves modifying SDL/src/video/SDL_pixels.c Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue: if (Rmask == 0x003F && Gmask == 0x07C0 && Bmask == 0xF800 && Amask == 0x0000) { return SDL_PIXELFORMAT_RGB565; } I hope that this helps someone. I took me a while to figure it out.
4a9c6f0a	2017-08-12T15:55:54	Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress Yann Dirson When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it to the user. Pushed a fix to: https://github.com/O-Computers/SDL/commit/f94cb13708ef4d236f8a2a330135b9b3a47db204 Note that the "OpenGL library not loaded" error looks like no root cause either, and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead of the x11 one, I suspect even more accurate info can be given to user.
b1ed855d	2017-08-12T15:45:46	Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts See bug 3188 for more discussion
3b837a26	2017-08-12T15:41:03	Fixed bug 3188 - AZERTY keyboard support broken and inconsistent Daniel Gibson AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift. On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY. I don't know how other platforms behave. So we have two problems: 1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned 2. Different platforms behave differently (Windows vs Linux/OSX) It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)? Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes? This bug on the mailing list: https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows) https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
1a544145	2017-08-12T15:21:26	Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey Sylvain Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation. When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255). I think SDL_ConvertSurface should strictly keeps the input format. example ======= SDL_Surface input; // ... Set up a surface with ColorKey and no AlphaMod SDL_Surface output = SDL_ConvertSurface(input, input->format, input->flags); // "output" surface has a ColorKey but also AlphaMod (BLEND, and Opaque 255).
e4124ff5	2017-08-12T15:00:33	Fixed bug 3208 - Minor improvements to the configure script Rafal Muzylo "if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)
2862b146	2017-08-12T13:05:26	Note that texture contents are undefined when the texture is created.
6f843b90	2017-08-12T12:59:22	Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0 Simon Hug The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white. The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
47c2c7d5	2017-08-12T12:56:28	Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
195b8bd8	2017-08-12T12:34:09	Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events Adam M. The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued". For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key. If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT). You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event. Not only is it inconsistent with itself, I think it makes keyboard processing harder. The problem is near line 740 in SDL_keyboard.c: if (SDL_KEYDOWN == type) { modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN? switch (keycode) { case SDLK_NUMLOCKCLEAR: keyboard->modstate ^= KMOD_NUM; break; case SDLK_CAPSLOCK: keyboard->modstate ^= KMOD_CAPS; break; default: keyboard->modstate \|= modifier; break; } } else { keyboard->modstate &= ~modifier; modstate = keyboard->modstate; } In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.
c0862512	2017-08-12T12:24:59	Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls. owen I removed all the static variables from SDLActivity.java Updated all the SDL_android.c jni calls as well I added a new function to SDL_android.c/ h void Android_JNI_SeparateEventsHint(const char* c); This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.
0a52db54	2017-08-12T08:15:09	Fixed bug 3191 - haptic system on android? Patch provided by jintiao and Milan Nikolic, thanks!
78c84e70	2017-08-12T08:06:16	Fixed part of bug 3227 - patch for multiple buttons at the same time not working Philipp Wiesemann There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.
b425050b	2017-08-12T00:04:46	Fixed compiler warnings on Visual Studio 2013
affab6ad	2017-08-12T00:01:24	More fixes for the SDL_scanf code
e27dcd1c	2017-08-11T23:54:06	Fixed Android build
7229397c	2017-08-11T21:47:31	Fixed bug 3258 - SDL_TryLockMutex blocks for pthreads with FAKE_RECURSIVE_MUTEX Ian Abbott I just spotted what I think is a bug in "src/thread/pthread/SDL_sysmutex.c" in the SDL_TryLockMutex function when FAKE_RECURSIVE_MUTEX is defined (for an implementation of Pthreads with no recursive mutex support). It calls pthread_mutex_lock instead of pthread_mutex_trylock, so it will block until the mutex is available instead of returning SDL_MUTEX_TIMEDOUT if it cannot lock the mutex immediately.
b5ea3c6d	2017-08-11T21:30:06	Fixed bug 3284 - minor correction for SDL_setenv on _WIN32__ platform Coriiander Here is a minor correction for a non-breaking mistake in SDL_setenv for __WIN32__ platform. See below for details. FILE: "SDL/src/stdlib/SDL_getenv.c" FUNCTION: (__WIN32__ platform) int SDL_setenv(const char name, const char value, int overwrite) CODE: if (!overwrite) { char ch = 0; const size_t len = GetEnvironmentVariableA(name, &ch, sizeof (ch)); if (len > 0) { return 0; /* asked not to overwrite existing value. / } } WHAT'S WRONG: The 3th argument to GetEnvironmentVariable (being DWORD nSize) must be the number of characters, not the number of bytes. SDL currently passes "the size of 1 char", rather "1". While it is non-breaking (1=1 after all), it is incorrect. Furthermore there is no need to specify the 2nd and 3th arguments at all. CORRECTION 1: (corrected argument_ if (!overwrite) { char ch = 0; const size_t len = GetEnvironmentVariableA(name, &ch, 1); if (len > 0) { return 0; / asked not to overwrite existing value. / } } CORRECTION 2: (stripped of unneeded code) if (!overwrite) { if (GetEnvironmentVariableA(name, NULL, 0) > 0) { return 0; / asked not to overwrite existing value. */ } }
75d5f343	2017-08-11T21:17:10	Forgot to add function check for fopen64 to CMake build
a48c9e6d	2017-08-11T21:16:33	Fixed bug 3292 - SDL_rwops and 64-bit file I/O Juha Niemim? On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
4c239e55	2017-08-11T20:54:06	Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP Littlefighter19 When trying to mirror something on the PSP, I've stumbled upon the problem, that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally. Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
79a846d4	2017-08-11T19:42:39	Fixed bug 3334 - SDL_ShowMessageBox uses wrong index and accesses un-allocated memory romain.lacroix For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox() The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton(). It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button. It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : buttonid = buttons[which].buttonid;) However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons. When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to buttonId is uninitialized memory (random value). The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.
441d9ba2	2017-08-11T19:36:12	Fixed bug 3341 - SDL_sscanf() problem e_pluschauskas Why does SDL_sscanf() always returns the number of format specifiers and doesn't implements standard C library behavior?
1da252c2	2017-08-11T18:56:41	Fixed crash in bug 3367 - RGBA_FROM_PIXEL macro can't handle SDL_PIXELFORMAT_ARGB2101010 Simon Hug The RGBA_FROM_PIXEL macro in src/video/blit.h [1] is not designed to work with more than 8 bits per channel and the ARGB2101010 format makes it read outside of the array bounds causing access violations. This can happen during blitting with the BlitNtoNPixelAlpha and SDL_Blit_Slow functions. When SDL_InitFormat tries to calculate the loss of the channels [2], the Uint8 will wrap around and it will end up at 254 for the 10-bit channels. Clearly way over the 9 entries of the SDL_expand_byte array. (Not that a signed integer would help.) Then the macro tries to access the lookup table with the channel value which could be up to 1023. If the previous indirection didn't cause an access violation this one will. I guess it's not worth modifying this macro for a format that only a few will use. It will only make the other blitters slower. I don't have good ideas to solve this issue. Attached is a test case that does three blits. A copy one that work and the two that use the functions mentioned above. [1] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_blit.h#l303 [2] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_pixels.c#l540
df5898b0	2017-08-11T13:37:40	Fixed bug 3464 - Fix for Android hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH ny00 According to the current documentation in SDL_hints.h, if SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH is set to "0" (or not set at all) then mouse input should lead to touch events, along with corresponding fake mouse events with mouse id SDL_TOUCH_MOUSEID. However, while moving a mouse around (actually using a trackpad identified as a mouse), I get SDL mouse motion events with differing mouse ids, as follows: - If the mouse is moved while a mouse button is pressed, the mouse id is SDL_TOUCH_MOUSEID. - Otherwise, the mouse id for mouse motion events is 0. I've attached sample code for reference, which includes logs of the various mouse events (the "which" field is covered). I believe that no actual mouse event should arrive, if the hint is unset. In particular, no mouse motion event should arrive while no mouse button is pressed. I'm going to attach a patch which resolves this, while also disabling mouse wheel motion events.
b3589ed6	2017-08-11T13:24:18	Fixed bug 3492 - SDL_RenderCopyEx angle direction not documented xyzdragon Reading https://wiki.libsdl.org/SDL_RenderCopyEx there is no mention what the angle means. Normally in a mathematically environment positive angles translate to counter-clockwise rotations, but in SDL positive angles means clockwise rotation.
6de66e98	2017-08-11T11:54:24	Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer Daniel SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates. SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.
658975f3	2017-08-11T11:32:00	Fixed bug 3639 - SDL_GetPrefPath returns a path with two consecutive slashes on Unix if org is omitted Fabian Greffrath we use SDL_GetPrefPath() in Chocolate Doom to get a reasonable directory to save and restore config files and savegames: https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/m_config.c#L2162 However, since there is no "organization" behind Chocolate Doom and there is really only one "product" called Chocolate Doom, we pass an empty string for the org parameter and the package string for app. This leads to two consecutive slashes in the path returned by SDL_GetPrefPath() like this: /home/user/.local/share//chocolate-doom/ While this is harmless, it sure looks bad. I believe that it should be possible to either pass a NULL pointer for the org parameter or at least have the function detect an empty string as a means to express "there is no origanization, just a single product". The generation of the path string to be returned by the function will have to get adapted accordingly.
3c852360	2017-08-11T10:42:26	Fixed bug 3646 - SDL_test_common.c: Add key bindings for testing SDL_SetWindowPosition Eric Wasylishen Alt-Up/Down/Left/Right switches between displays using SDL_WINDOWPOS_CENTERED_DISPLAY Shift-Up/Down/Left/Right shifts the window by 100px
222bacd8	2017-08-11T10:32:47	Fixed bug 3682 - Toggle text input in checkkeys when the mouse is clicked Eric Wasylishen Small change to checkkeys so you can toggle text input mode with a mouse click. This is needed for testing how dead keys react to toggling mouse input, i.e. these bugs:
96305832	2017-08-11T10:21:19	Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries Simon Hug Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.
6e1b11ba	2017-08-11T10:18:45	Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling Eric Wasylishen 2017-07-26 18:42:58 UTC I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3). The displays are arranged from left to right: Display #1 (main): 2880x1800, 200% scaling Display #2: 1920x1200, 150% scaling Display #3: 1920x1080, 100% scaling SDL display bounds: INFO: Bounds: 1440x900 at 0,0 INFO: Bounds: 1281x801 at 1921,0 (these are incorrect) INFO: Bounds: 1920x1080 at 4800,0 Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback: 1440x900 at (0, 0) 1280x800 at (2880, 0) 1920x1080 at (4800, 0) It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others. Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709 SDL: current hg (11235:6a587b9e0ec8) Windows 10, Version 10.0.15063 Build 15063 Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop. This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display. With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug) The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
a05522a0	2017-08-11T10:05:45	Fixed bug 3723 - Possible double free in kmsdrm init code on certain errors Simon Hug KMSDRM_VideoInit allocates and frees some connectors and encoders but doesn't set the pointer to NULL after freeing. The cleanup code at the end may free one of those garbage pointer should an error happen in the initialization.
d0b46f1b	2017-08-10T11:57:19	Fixed bug 3681 - SDL_UpateTexture documentation not specific enough about format requirement Simon Hug The documentation of SDL_UpateTexture does not say that the pixel data has to be in the format of the texture.
843293be	2017-08-09T20:26:16	Fixed bug 3701 - WM_TOUCH message may cause calls to null if touch functions are not properly loaded Simon Hug When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.
a47bf374	2017-08-09T20:23:48	Fixed bug 3728 - [Android] crash when shared libraries are no loaded Sylvain On Android, when shared libraries are not correctly loaded (eg SDLActivity.mBrokenLibraries is true), there is a pop-up with an error message. After user dismisses the pop-up, application crashes: - because the native function "nativePause()" may no be loaded (if libSDL2.so is not loaded). - because mSurface is null.
af44a595	2017-08-09T20:20:35	Fixed bug 3672 - Add joystick to controllerdb Moritz M-H The following entry needs to be added to the gamecontrollerdb for the Qanba fighter stick under linux
73c6cebb	2017-08-09T22:43:16	cmake: Pacify warning about Policy CMP0042 not being set.
80c6c2fa	2017-08-09T22:34:45	cmake: whoops, Sam and I both fixed this bug at the same time. :)
496337b3	2017-08-09T19:03:10	Fixed bug 3651 - CMake build does not install CMake package configuration tschwinger@elitemail.org Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely. A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details). I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons: 1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles. 2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere. Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`). https://github.com/tschw/SDL/commits/patched Fixing #2576 #3572, #3613, and this fresh ticket, which is almost entirely advertisement ;). These already do to make SDL much less of a quirky fella to have in your dependency tree...
d3af447e	2017-08-09T18:47:33	Fixed bug 3590 - CMAKE: typos in CheckMir Martin Gerhardy - list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CLFAGS} ${XKB_CLFLAGS}) + list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CFLAGS} ${XKB_CFLAGS}) CFLAGS is spelled wrong in two different ways for EGL and XKB And while you are on it... sdl needs mir >= 0.24 afaik - it fails on travis-ci (ubuntu 14.04 LTS with 0.18 installed and in other environments, too (e.g. https://github.com/urho3d/Urho3D/issues/1685) To fix this one should add a min version check to pkg_check_modules like this - pkg_check_modules(MIR_TOOLKIT mirclient mircommon) + pkg_check_modules(MIR_TOOLKIT mirclient>=0.24 mircommon)
1b8117be	2017-08-09T19:50:18	cmake: Don't link directly against a libpthread on Android (thanks, Anthony!). Android has pthreads, but it's just part of their C runtime instead of a separate library like the usual Linux platforms. Fixes Bugzilla #3675.
53d4f5c9	2017-08-09T16:20:04	Fixed bug 3733 - Makefile sleeps for 3 seconds if configure is out of date
2d67381a	2017-08-09T18:41:59	haiku: non-x86 spins use a normal libstdc++ filename. Handle the differences. Fixes Bugzilla #3730.
69092c7e	2017-08-09T18:30:48	haiku: Fixed compiler warning.
03250690	2017-08-09T12:38:20	Added a private hint for Steam to bypass the controller filtering for the Steam virtual gamepad
f15dbc8f	2017-08-09T12:11:59	Fixed Linux build
c49fa37c	2017-08-09T11:59:29	Added SDL hints to filter the set of game controllers reported by SDL
dc400184	2017-08-09T11:58:38	Added an API SDL_LoadFile_RW() to load all the data from an SDL data stream, and a convenience macro SDL_LoadFile() to load all the data from a file.
a412ba0d	2017-08-09T01:01:41	haiku: Patched SDL_bopengl.cc to compile on x86-64 Haiku. Fixes Bugzilla #3729.
d5215d9d	2017-08-09T00:56:05	Fixed up some compile warnings and errors on x86-64 Haiku.
64c29577	2017-08-09T00:55:27	Added a FIXME for 2.1 about an API change.
4e43c631	2017-08-08T20:38:23	Re-added missing entry for the Steam Virtual Gamepad (was Valve Streaming Gamepad)
ef54d5a8	2017-08-07T10:28:59	Fixed building on various versions of GCC - YUV MMX code is disabled for now
76306827	2017-08-07T00:36:45	README-linux.md: added libsndio-dev to the package list.
9dde37ea	2017-08-07T00:25:18	sndio: Fix for some platforms (Linux, for example) that don't define INFTIM. Fixes Bugzilla #3712.
27de835d	2017-08-05T22:10:55	emscripten: Fixed compiler warnings about integer to pointer conversions. Found by buildbot.
711df8a9	2017-08-05T22:10:48	emscripten: Fixed compiling without OpenGL support.
f216b446	2017-08-05T22:10:36	kmsdrm: Fixed crashes if allocating memory failed.
b8a7dd77	2017-08-05T22:10:25	nacl: Fixed freeing static memory on video quit.
1f698469	2017-08-05T22:10:15	mir: Removed unnecessary function declaration.
e9ae411a	2017-08-04T23:01:01	Updated generated configure script.
4723943b	2017-08-04T23:00:47	kmsdrm: Fixed compiling without OpenGL support.
8aa147fa	2017-08-04T23:00:30	Fixed compiler warnings about type conversions. Found by buildbot.
a09efc73	2017-08-04T16:18:34	psp: Force audio channels to stereo if > 2 channels requested (thanks, Solra!). Fixes Bugzilla #3726.
cc5ceb11	2017-08-04T13:06:56	Temporary hack to fix bug 3725 - Call made to glGetString before context creation This breaks bugs 2570, 3145
56cab6d4	2017-08-03T09:48:44	Added a hint SDL_HINT_TOUCH_MOUSE_EVENTS to control whether touch events generate synthetic mouse events.
86e95a60	2017-08-02T17:45:15	kmsdrm: Fix tearing in neverputt/ball https://gfycat.com/FatalFarawayHeron
c544d2b9	2017-08-02T23:42:08	Add support for Saitek P990 Dual Analog Pad
fca91451	2017-08-02T13:51:14	kmsdrm: Fix leaking SDL_VideoDevice*
9dbe5a96	2017-08-02T13:38:46	Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS Eric wing Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark. I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template. Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part). When you click/touch, it will draw one more happy face where your button point is. If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.) Alex Szpakowski on the mailing list suggests the problem is "I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)." Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
082f32d1	2017-08-02T10:28:13	Fixed bug 3722 - Fall back to xinerama/xvidmode if xrandr modes initialization fails Levi Bard In some environments, xrandr modes initialization can fail even though xrandr support is present and of a sufficient version. (The one I encountered was an AWS instance running a virtual display) The attached patch allows SDL to keep trying other methods if xrandr modes initialization fails (still subject to SDL_VIDEO_X11_REQUIRE_XRANDR).
4be06670	2017-08-02T10:24:47	Fixed potential free of uninitialized memory (thanks Simon!)
56363ebf	2017-08-02T10:22:48	Fixed bug 3690 - SDL2 KMS/DRM render context support Manuel The attached patch adds support for KMS/DRM context graphics. It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation. Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition. X86 systems use KMS right away in every current GNU/Linux system. Simple build instructions: $./autogen.sh $./configure --enable-video-kmsdrm $make
997c69b9	2017-08-01T20:16:10	Fixed bug 3697 - Main thread gets stuck on left mouse down Eric Wasylishen I think I found a better fix. The problem with https://hg.libsdl.org/SDL/rev/ebdc0738b1b5 is setting the styleMask to 0 clears the NSWindowStyleMaskFullScreen bit, which then confuses Cocoa later when you try to leave fullscreen. Instead I'm just clearing the NSWindowStyleMaskResizable bit, although SetWindowStyle(window, NSWindowStyleMaskFullScreen); seems to also work.

2da830a9

2017-08-13T21:15:44

Fixed bug 3741 - more compatible initializers for arrays Ozkan Sezer An array defined like int xPositions[] = {-1, 0, 1, w-1, w, w+1 }; errors with Open Watcom: it strictly wants constants. Small patch like below makes things more compatible.

93a520b3

2017-08-13T21:12:14

Fixed bug 3605 - Software renderer no longer renders after Android screen orientation change Sylvain This still happens with the current trunk version. (software renderer of testdrawchessboard.c) When there is a rotation, the window size changed and the internal surface is marked as "surface_valid == SDL_FALSE". And all further call fails. SDL_video.c : 2478 void 2479 SDL_OnWindowResized(SDL_Window * window) 2480 { 2481 window->surface_valid = SDL_FALSE; 2482 SDL_SendWindowEvent(window, SDL_WINDOWEVENT_SIZE_CHANGED, window->w, window->h); 2483 } some error set to : 2233 return SDL_SetError("Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface"); So, this seems to be the behavior of the API ... In the loop() function of testdrawchessboard.c, we can recreate the surface/renderer : 65 if (e.type == SDL_WINDOWEVENT) 66 { 67 if (e.window.event == SDL_WINDOWEVENT_SIZE_CHANGED) 68 { 69 surface = SDL_GetWindowSurface(window); 70 renderer = SDL_CreateSoftwareRenderer(surface); 71 } 72 /* Clear the rendering surface with the specified color */ 73 SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF); 74 SDL_RenderClear(renderer); 75 } And it displays correctly.

3cae0c38

2017-08-13T21:09:00

Fixed bug 3746 - remove SDLCALL attribute from SDL_BlitFunc() funcptr Ozkan Sezer The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr. As far as I can see, *SDL_BlitFunc() is completely internal to SDL with no specific calling convention requirements. The actual functions assigned to SDL_BlitFunc seem to not have any calling conventions specified. So, easy solution is simply removing the strict calling convention from the type.

ca5c3048

2017-08-13T21:06:52

Fixed bug 3744 - missing SDLCALL in several functions Ozkan Sezer The attached patch adds missing SDLCALL to several functions, so that they properly match the headers as intended.

e54eede2

2017-08-13T21:05:15

Provide the correct state of the on-screen keyboard to the API (patch from Sylvain)

6ee66139

2017-08-13T20:55:59

Fixed bug 3235 - Make the Android window creation similar to iOS' window creation Sylvain Here's a patch. It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window. setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass. Some artefact observed : surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.

6ef1a25d

2017-08-13T20:51:08

Fixed bug 3751 - DirectFB linux_input disabled by default Clayton Craft linux_input module is disabled by default, despite the comments in source code that it is otherwise: src/video/directfb/SDL_DirectFB_video.c: devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0); /* default: on */ src/video/directfb/SDL_DirectFB_video.h: #define DFBENV_USE_LINUX_INPUT "SDL_DIRECTFB_LINUX_INPUT" /* Default: on */ When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!

ddeaa601

2017-08-13T20:42:41

Fixed bug 3299 - DirectInput: Incorrect joystick mapping when attaching new joysticks Jimb Esser Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput. I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)). The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.

ea9bc659

2017-08-13T20:39:00

Added check for XBOX in addition to Xbox and X-Box

78865eff

2017-08-13T20:38:06

Fixed compiler warning

f1829d95

2017-08-13T20:37:49

Added SDL_wcscmp()

af9ec8f6

2017-08-13T20:13:11

Fixed copy-paste error, thanks Alen!

df2d2994

2017-08-13T18:12:06

Fixed bug 2812 - Make libSDL2main.a usable on Android via a dummy symbol Jonas Kulla This eliminates the need to manually compile in SDL_main_android.c. Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking. I don't know how the nkd-build process works, but unless it was for some reason linking libSDL2main.a it should be unaffected.

e9772259

2017-08-13T17:59:59

Fixed bug 2839 - No way to create pre-built libraries for Android Mark Callow README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries. Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module. Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.

c87e1d52

2017-08-13T14:15:52

Fixed bug 2841 - Hint to set resource id for window icon Alexey Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.

18cceb5c

2017-08-13T01:00:01

x11: Patched to compile.

0a1b905b

2017-08-13T00:58:23

x11: Fix message box titles with Unicode chars on some window managers. Fixes Bugzilla #2971.

bfd5a134

2017-08-12T20:25:49

Fixed bug 2931 - Large relative mouse motion jumps when using touch input

b2e2bcc2

2017-08-12T20:21:34

Added test debug logs for additional event types

9be597a0

2017-08-12T22:16:04

iOS: Fix app orientation when creating a landscape fullscreen window with the device currently in portrait orientation.

059d9e46

2017-08-12T17:41:59

Fixed bug 2950 - wrong axes values are set on joystick initialization Edward Rudd Device: Logitech Rumble Gamepad F510 in Xinput mode. Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time. This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers. Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect. Here is my current workaround in the game I'm working on porting.. SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1"); SDL_GameController* gamepad = SDL_GameControllerOpen(index); SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");

7bab2913

2017-08-12T17:01:14

Fixed Windows build

05facb3d

2017-08-12T16:59:00

Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently Edmund Horner When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels. In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected. I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).

d226594f

2017-08-12T16:48:46

Workaround for bug 3049 - SDL_Init(SDL_INIT_VIDEO) - XDM authorization key matches an existing client! malferit Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console: XDM authorization key matches an existing client! I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config: DisplayManager*authName: MIT-MAGIC-COOKIE-1 I don't think an end user needs to know that... But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C. I run ldd to the two generated applications: Application in C: linux-gate.so.1 (0xffffe000) libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000) libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000) libc.so.6 => /lib/libc.so.6 (0xb74e2000) libm.so.6 => /lib/libm.so.6 (0xb74a0000) libdl.so.2 => /lib/libdl.so.2 (0xb749a000) librt.so.1 => /lib/librt.so.1 (0xb7491000) /lib/ld-linux.so.2 (0xb77b3000) Application compiled with Freepascal: linux-gate.so.1 (0xffffe000) libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000) libc.so.6 => /lib/libc.so.6 (0xb7367000) libm.so.6 => /lib/libm.so.6 (0xb7325000) libdl.so.2 => /lib/libdl.so.2 (0xb731f000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000) librt.so.1 => /lib/librt.so.1 (0xb72fc000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000) /lib/ld-linux.so.2 (0xb7755000) It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp . Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well. So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help. Hi, some tests: 1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11. 2. Enabled XDM. Added 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11. 3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.

45cec28b

2017-08-12T16:44:00

Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c Coriiander There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c". When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.

e3f3a757

2017-08-12T16:02:33

Fixed bug 3158 - SDL display window scrambled over VNC Witek Jachimczyk I'm using SDL to develop a video viewer for MATLAB. The window is scrambled while using thightVNC with its default mode of RGB656. SDL does not correctly recognize the pixel mode. I found a solution for this problem. The solution involves modifying SDL/src/video/SDL_pixels.c Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue: if (Rmask == 0x003F && Gmask == 0x07C0 && Bmask == 0xF800 && Amask == 0x0000) { return SDL_PIXELFORMAT_RGB565; } I hope that this helps someone. I took me a while to figure it out.

4a9c6f0a

2017-08-12T15:55:54

Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress Yann Dirson When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it to the user. Pushed a fix to: https://github.com/O-Computers/SDL/commit/f94cb13708ef4d236f8a2a330135b9b3a47db204 Note that the "OpenGL library not loaded" error looks like no root cause either, and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead of the x11 one, I suspect even more accurate info can be given to user.

b1ed855d

2017-08-12T15:45:46

Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts See bug 3188 for more discussion

3b837a26

2017-08-12T15:41:03

Fixed bug 3188 - AZERTY keyboard support broken and inconsistent Daniel Gibson AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift. On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY. I don't know how other platforms behave. So we have two problems: 1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned 2. Different platforms behave differently (Windows vs Linux/OSX) It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)? Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes? This bug on the mailing list: https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows) https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).

1a544145

2017-08-12T15:21:26

Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey Sylvain Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation. When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255). I think SDL_ConvertSurface should strictly keeps the input format. example ======= SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags); // "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).

e4124ff5

2017-08-12T15:00:33

Fixed bug 3208 - Minor improvements to the configure script Rafal Muzylo "if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)

2862b146

2017-08-12T13:05:26

Note that texture contents are undefined when the texture is created.

6f843b90

2017-08-12T12:59:22

Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0 Simon Hug The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white. The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.

47c2c7d5

2017-08-12T12:56:28

Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.

195b8bd8

2017-08-12T12:34:09

Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events Adam M. The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued". For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key. If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT). You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event. Not only is it inconsistent with itself, I think it makes keyboard processing harder. The problem is near line 740 in SDL_keyboard.c: if (SDL_KEYDOWN == type) { modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN? switch (keycode) { case SDLK_NUMLOCKCLEAR: keyboard->modstate ^= KMOD_NUM; break; case SDLK_CAPSLOCK: keyboard->modstate ^= KMOD_CAPS; break; default: keyboard->modstate |= modifier; break; } } else { keyboard->modstate &= ~modifier; modstate = keyboard->modstate; } In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.

c0862512

2017-08-12T12:24:59

Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls. owen I removed all the static variables from SDLActivity.java Updated all the SDL_android.c jni calls as well I added a new function to SDL_android.c/ h void Android_JNI_SeparateEventsHint(const char* c); This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.

0a52db54

2017-08-12T08:15:09

Fixed bug 3191 - haptic system on android? Patch provided by jintiao and Milan Nikolic, thanks!

78c84e70

2017-08-12T08:06:16

Fixed part of bug 3227 - patch for multiple buttons at the same time not working Philipp Wiesemann There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.

b425050b

2017-08-12T00:04:46

Fixed compiler warnings on Visual Studio 2013

affab6ad

2017-08-12T00:01:24

More fixes for the SDL_scanf code

e27dcd1c

2017-08-11T23:54:06

Fixed Android build

7229397c

2017-08-11T21:47:31

Fixed bug 3258 - SDL_TryLockMutex blocks for pthreads with FAKE_RECURSIVE_MUTEX Ian Abbott I just spotted what I think is a bug in "src/thread/pthread/SDL_sysmutex.c" in the SDL_TryLockMutex function when FAKE_RECURSIVE_MUTEX is defined (for an implementation of Pthreads with no recursive mutex support). It calls pthread_mutex_lock instead of pthread_mutex_trylock, so it will block until the mutex is available instead of returning SDL_MUTEX_TIMEDOUT if it cannot lock the mutex immediately.

b5ea3c6d

2017-08-11T21:30:06

Fixed bug 3284 - minor correction for SDL_setenv on _WIN32__ platform Coriiander Here is a minor correction for a non-breaking mistake in SDL_setenv for __WIN32__ platform. See below for details. FILE: "SDL/src/stdlib/SDL_getenv.c" FUNCTION: (__WIN32__ platform) int SDL_setenv(const char *name, const char *value, int overwrite) CODE: if (!overwrite) { char ch = 0; const size_t len = GetEnvironmentVariableA(name, &ch, sizeof (ch)); if (len > 0) { return 0; /* asked not to overwrite existing value. */ } } WHAT'S WRONG: The 3th argument to GetEnvironmentVariable (being DWORD nSize) must be the number of characters, not the number of bytes. SDL currently passes "the size of 1 char", rather "1". While it is non-breaking (1=1 after all), it is incorrect. Furthermore there is no need to specify the 2nd and 3th arguments at all. CORRECTION 1: (corrected argument_ if (!overwrite) { char ch = 0; const size_t len = GetEnvironmentVariableA(name, &ch, 1); if (len > 0) { return 0; /* asked not to overwrite existing value. */ } } CORRECTION 2: (stripped of unneeded code) if (!overwrite) { if (GetEnvironmentVariableA(name, NULL, 0) > 0) { return 0; /* asked not to overwrite existing value. */ } }

75d5f343

2017-08-11T21:17:10

Forgot to add function check for fopen64 to CMake build

a48c9e6d

2017-08-11T21:16:33

Fixed bug 3292 - SDL_rwops and 64-bit file I/O Juha Niemim? On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.

4c239e55

2017-08-11T20:54:06

Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP Littlefighter19 When trying to mirror something on the PSP, I've stumbled upon the problem, that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally. Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c

79a846d4

2017-08-11T19:42:39

Fixed bug 3334 - SDL_ShowMessageBox uses wrong index and accesses un-allocated memory romain.lacroix For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox() The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton(). It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button. It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : *buttonid = buttons[which].buttonid;) However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons. When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to *buttonId is uninitialized memory (random value). The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.

441d9ba2

2017-08-11T19:36:12

Fixed bug 3341 - SDL_sscanf() problem e_pluschauskas Why does SDL_sscanf() always returns the number of format specifiers and doesn't implements standard C library behavior?

1da252c2

2017-08-11T18:56:41

Fixed crash in bug 3367 - RGBA_FROM_PIXEL macro can't handle SDL_PIXELFORMAT_ARGB2101010 Simon Hug The RGBA_FROM_PIXEL macro in src/video/blit.h [1] is not designed to work with more than 8 bits per channel and the ARGB2101010 format makes it read outside of the array bounds causing access violations. This can happen during blitting with the BlitNtoNPixelAlpha and SDL_Blit_Slow functions. When SDL_InitFormat tries to calculate the loss of the channels [2], the Uint8 will wrap around and it will end up at 254 for the 10-bit channels. Clearly way over the 9 entries of the SDL_expand_byte array. (Not that a signed integer would help.) Then the macro tries to access the lookup table with the channel value which could be up to 1023. If the previous indirection didn't cause an access violation this one will. I guess it's not worth modifying this macro for a format that only a few will use. It will only make the other blitters slower. I don't have good ideas to solve this issue. Attached is a test case that does three blits. A copy one that work and the two that use the functions mentioned above. [1] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_blit.h#l303 [2] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_pixels.c#l540

df5898b0

2017-08-11T13:37:40

Fixed bug 3464 - Fix for Android hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH ny00 According to the current documentation in SDL_hints.h, if SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH is set to "0" (or not set at all) then mouse input should lead to touch events, along with corresponding *fake* mouse events with mouse id SDL_TOUCH_MOUSEID. However, while moving a mouse around (actually using a trackpad identified as a mouse), I get SDL mouse motion events with differing mouse ids, as follows: - If the mouse is moved while a mouse button is pressed, the mouse id is SDL_TOUCH_MOUSEID. - Otherwise, the mouse id for mouse motion events is 0. I've attached sample code for reference, which includes logs of the various mouse events (the "which" field is covered). I believe that no actual mouse event should arrive, if the hint is unset. In particular, no mouse motion event should arrive while no mouse button is pressed. I'm going to attach a patch which resolves this, while also disabling mouse wheel motion events.

b3589ed6

2017-08-11T13:24:18

Fixed bug 3492 - SDL_RenderCopyEx angle direction not documented xyzdragon Reading https://wiki.libsdl.org/SDL_RenderCopyEx there is no mention what the angle means. Normally in a mathematically environment positive angles translate to counter-clockwise rotations, but in SDL positive angles means clockwise rotation.

6de66e98

2017-08-11T11:54:24

Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer Daniel SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates. SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.

658975f3

2017-08-11T11:32:00

Fixed bug 3639 - SDL_GetPrefPath returns a path with two consecutive slashes on Unix if org is omitted Fabian Greffrath we use SDL_GetPrefPath() in Chocolate Doom to get a reasonable directory to save and restore config files and savegames: https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/m_config.c#L2162 However, since there is no "organization" behind Chocolate Doom and there is really only one "product" called Chocolate Doom, we pass an empty string for the org parameter and the package string for app. This leads to two consecutive slashes in the path returned by SDL_GetPrefPath() like this: /home/user/.local/share//chocolate-doom/ While this is harmless, it sure looks bad. I believe that it should be possible to either pass a NULL pointer for the org parameter or at least have the function detect an empty string as a means to express "there is no origanization, just a single product". The generation of the path string to be returned by the function will have to get adapted accordingly.

3c852360

2017-08-11T10:42:26

Fixed bug 3646 - SDL_test_common.c: Add key bindings for testing SDL_SetWindowPosition Eric Wasylishen Alt-Up/Down/Left/Right switches between displays using SDL_WINDOWPOS_CENTERED_DISPLAY Shift-Up/Down/Left/Right shifts the window by 100px

222bacd8

2017-08-11T10:32:47

Fixed bug 3682 - Toggle text input in checkkeys when the mouse is clicked Eric Wasylishen Small change to checkkeys so you can toggle text input mode with a mouse click. This is needed for testing how dead keys react to toggling mouse input, i.e. these bugs:

96305832

2017-08-11T10:21:19

Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries Simon Hug Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.

6e1b11ba

2017-08-11T10:18:45

Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling Eric Wasylishen 2017-07-26 18:42:58 UTC I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3). The displays are arranged from left to right: Display #1 (main): 2880x1800, 200% scaling Display #2: 1920x1200, 150% scaling Display #3: 1920x1080, 100% scaling SDL display bounds: INFO: Bounds: 1440x900 at 0,0 INFO: Bounds: 1281x801 at 1921,0 (these are incorrect) INFO: Bounds: 1920x1080 at 4800,0 Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback: 1440x900 at (0, 0) 1280x800 at (2880, 0) 1920x1080 at (4800, 0) It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others. Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709 SDL: current hg (11235:6a587b9e0ec8) Windows 10, Version 10.0.15063 Build 15063 Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop. This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display. With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug) The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.

a05522a0

2017-08-11T10:05:45

Fixed bug 3723 - Possible double free in kmsdrm init code on certain errors Simon Hug KMSDRM_VideoInit allocates and frees some connectors and encoders but doesn't set the pointer to NULL after freeing. The cleanup code at the end may free one of those garbage pointer should an error happen in the initialization.

d0b46f1b

2017-08-10T11:57:19

Fixed bug 3681 - SDL_UpateTexture documentation not specific enough about format requirement Simon Hug The documentation of SDL_UpateTexture does not say that the pixel data has to be in the format of the texture.

843293be

2017-08-09T20:26:16

Fixed bug 3701 - WM_TOUCH message may cause calls to null if touch functions are not properly loaded Simon Hug When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.

a47bf374

2017-08-09T20:23:48

Fixed bug 3728 - [Android] crash when shared libraries are no loaded Sylvain On Android, when shared libraries are not correctly loaded (eg SDLActivity.mBrokenLibraries is true), there is a pop-up with an error message. After user dismisses the pop-up, application crashes: - because the native function "nativePause()" may no be loaded (if libSDL2.so is not loaded). - because mSurface is null.

af44a595

2017-08-09T20:20:35

Fixed bug 3672 - Add joystick to controllerdb Moritz M-H The following entry needs to be added to the gamecontrollerdb for the Qanba fighter stick under linux

73c6cebb

2017-08-09T22:43:16

cmake: Pacify warning about Policy CMP0042 not being set.

80c6c2fa

2017-08-09T22:34:45

cmake: whoops, Sam and I both fixed this bug at the same time. :)

496337b3

2017-08-09T19:03:10

Fixed bug 3651 - CMake build does not install CMake package configuration tschwinger@elitemail.org Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely. A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details). I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons: 1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles. 2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere. Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`). https://github.com/tschw/SDL/commits/patched Fixing #2576 #3572, #3613, and this fresh ticket, which is almost entirely advertisement ;). These already do to make SDL much less of a quirky fella to have in your dependency tree...

d3af447e

2017-08-09T18:47:33

Fixed bug 3590 - CMAKE: typos in CheckMir Martin Gerhardy - list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CLFAGS} ${XKB_CLFLAGS}) + list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CFLAGS} ${XKB_CFLAGS}) CFLAGS is spelled wrong in two different ways for EGL and XKB And while you are on it... sdl needs mir >= 0.24 afaik - it fails on travis-ci (ubuntu 14.04 LTS with 0.18 installed and in other environments, too (e.g. https://github.com/urho3d/Urho3D/issues/1685) To fix this one should add a min version check to pkg_check_modules like this - pkg_check_modules(MIR_TOOLKIT mirclient mircommon) + pkg_check_modules(MIR_TOOLKIT mirclient>=0.24 mircommon)

1b8117be

2017-08-09T19:50:18

cmake: Don't link directly against a libpthread on Android (thanks, Anthony!). Android has pthreads, but it's just part of their C runtime instead of a separate library like the usual Linux platforms. Fixes Bugzilla #3675.

53d4f5c9

2017-08-09T16:20:04

Fixed bug 3733 - Makefile sleeps for 3 seconds if configure is out of date

2d67381a

2017-08-09T18:41:59

haiku: non-x86 spins use a normal libstdc++ filename. Handle the differences. Fixes Bugzilla #3730.

69092c7e

2017-08-09T18:30:48

haiku: Fixed compiler warning.

03250690

2017-08-09T12:38:20

Added a private hint for Steam to bypass the controller filtering for the Steam virtual gamepad

f15dbc8f

2017-08-09T12:11:59

Fixed Linux build

c49fa37c

2017-08-09T11:59:29

Added SDL hints to filter the set of game controllers reported by SDL

dc400184

2017-08-09T11:58:38

Added an API SDL_LoadFile_RW() to load all the data from an SDL data stream, and a convenience macro SDL_LoadFile() to load all the data from a file.

a412ba0d

2017-08-09T01:01:41

haiku: Patched SDL_bopengl.cc to compile on x86-64 Haiku. Fixes Bugzilla #3729.

d5215d9d

2017-08-09T00:56:05

Fixed up some compile warnings and errors on x86-64 Haiku.

64c29577

2017-08-09T00:55:27

Added a FIXME for 2.1 about an API change.

4e43c631

2017-08-08T20:38:23

Re-added missing entry for the Steam Virtual Gamepad (was Valve Streaming Gamepad)

ef54d5a8

2017-08-07T10:28:59

Fixed building on various versions of GCC - YUV MMX code is disabled for now

76306827

2017-08-07T00:36:45

README-linux.md: added libsndio-dev to the package list.

9dde37ea

2017-08-07T00:25:18

sndio: Fix for some platforms (Linux, for example) that don't define INFTIM. Fixes Bugzilla #3712.

27de835d

2017-08-05T22:10:55

emscripten: Fixed compiler warnings about integer to pointer conversions. Found by buildbot.

711df8a9

2017-08-05T22:10:48

emscripten: Fixed compiling without OpenGL support.

f216b446

2017-08-05T22:10:36

kmsdrm: Fixed crashes if allocating memory failed.

b8a7dd77

2017-08-05T22:10:25

nacl: Fixed freeing static memory on video quit.

1f698469

2017-08-05T22:10:15

mir: Removed unnecessary function declaration.

e9ae411a

2017-08-04T23:01:01

Updated generated configure script.

4723943b

2017-08-04T23:00:47

kmsdrm: Fixed compiling without OpenGL support.

8aa147fa

2017-08-04T23:00:30

Fixed compiler warnings about type conversions. Found by buildbot.

a09efc73

2017-08-04T16:18:34

psp: Force audio channels to stereo if > 2 channels requested (thanks, Solra!). Fixes Bugzilla #3726.

cc5ceb11

2017-08-04T13:06:56

Temporary hack to fix bug 3725 - Call made to glGetString before context creation This breaks bugs 2570, 3145

56cab6d4

2017-08-03T09:48:44

Added a hint SDL_HINT_TOUCH_MOUSE_EVENTS to control whether touch events generate synthetic mouse events.

86e95a60

2017-08-02T17:45:15

kmsdrm: Fix tearing in neverputt/ball https://gfycat.com/FatalFarawayHeron

c544d2b9

2017-08-02T23:42:08

Add support for Saitek P990 Dual Analog Pad

fca91451

2017-08-02T13:51:14

kmsdrm: Fix leaking SDL_VideoDevice*

9dbe5a96

2017-08-02T13:38:46

Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS Eric wing Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark. I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template. Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part). When you click/touch, it will draw one more happy face where your button point is. If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.) Alex Szpakowski on the mailing list suggests the problem is "I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)." Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".

082f32d1

2017-08-02T10:28:13

Fixed bug 3722 - Fall back to xinerama/xvidmode if xrandr modes initialization fails Levi Bard In some environments, xrandr modes initialization can fail even though xrandr support is present and of a sufficient version. (The one I encountered was an AWS instance running a virtual display) The attached patch allows SDL to keep trying other methods if xrandr modes initialization fails (still subject to SDL_VIDEO_X11_REQUIRE_XRANDR).

4be06670

2017-08-02T10:24:47

Fixed potential free of uninitialized memory (thanks Simon!)

56363ebf

2017-08-02T10:22:48

Fixed bug 3690 - SDL2 KMS/DRM render context support Manuel The attached patch adds support for KMS/DRM context graphics. It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation. Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition. X86 systems use KMS right away in every current GNU/Linux system. Simple build instructions: $./autogen.sh $./configure --enable-video-kmsdrm $make

997c69b9

2017-08-01T20:16:10

Fixed bug 3697 - Main thread gets stuck on left mouse down Eric Wasylishen I think I found a better fix. The problem with https://hg.libsdl.org/SDL/rev/ebdc0738b1b5 is setting the styleMask to 0 clears the NSWindowStyleMaskFullScreen bit, which then confuses Cocoa later when you try to leave fullscreen. Instead I'm just clearing the NSWindowStyleMaskResizable bit, although SetWindowStyle(window, NSWindowStyleMaskFullScreen); seems to also work.

kc3-lang/SDL

Log