kmx git

Commit	Date	Message
f00ddd0a	2020-03-02T11:39:44	Updated WhatsNew.txt with SDL 2.0.12 release notes
25061816	2020-03-02T10:58:08	Fixed compile warning
eb19631a	2020-03-02T10:57:57	This controller firmware is supported on Windows, and is covered by the Bluetooth check on Mac OSX
49564c8b	2020-03-02T10:47:48	Added support for the PDP Victrix Pro FS with Touch Pad for PS4
4572dd2a	2020-03-02T10:37:28	Fixed bug 4854 - Add a way to extend the values in controller_type.h Added a hint SDL_HINT_GAMECONTROLLERTYPE to allow overriding the built-in controller type database
27f346a0	2020-03-02T09:46:37	Fixed compile warning
339612d5	2020-03-02T09:35:12	ControllerList: add support for Victrix Pro FS w/ Touchpad for PS4
52be6633	2020-03-02T09:35:09	Use SDL math functions in Steam Controller support
756d2073	2020-03-02T09:26:12	Updated the HIDAPI Xbox One driver with support for Bluetooth Xbox One controllers
997f3e9e	2020-03-02T09:03:55	Fixed build warnings
11a84e4f	2020-03-01T18:16:15	Make sure hidapi is built for the release DMG
bebc4867	2020-03-01T17:53:30	We already have a hidapi implementation for Windows, we don't need libusb
74ed2156	2020-03-01T14:58:16	Updated version to 2.0.12 for release candidate build
6590d078	2020-03-01T14:52:49	Fixed bug 4996 - Mac: XBoxOne Bluetooth rumble isn't working rofferom I have an annoying issue on MacOS about XBoxOne Bluetooth rumble (Vendor: 0x045e, Product: 0x02fd). When 360controller is installed, rumble is working correctly. However, Bluetooth rumble isn't working at all, with or without 360controller installed (although it is working with Chrome + https://html5gamepad.com). I looked at the code, and it seems that XBox controllers are managed in MacOS in this file: SDL_hidapi_xbox360.c. The XBoxOne file is disabled for MacOS in SDL_hidjoystick_c.h. The function HIDAPI_DriverXbox360_Rumble() is called correctly, and hid_write() returns no error. I have tried a stupid test. I took the rumble packet from 360controller: https://github.com/360Controller/360Controller/blob/ec4e88eb2d2535e9b32561c702f42fb22b0a7f99/XBOBTFF/FFDriver.cpp#L620. With the patch I have attached, I manage to have rumble working on Bluetooth (with some stupid vibration level, but it proves it can if the packet is changed). But it breaks the USB rumble with 360controller. A comment in the function makes an explicit reference to 360controller, I think that's why I have broken this specific usecase. I don't know what is the correct way to fix this, but it seems that the current implementation has a missing case for Bluetooth support. Note that I also tested master this morning, and I have another issue: if (!device->ffservice) { return SDL_Unsupported(); } test fails in DARWIN_JoystickRumble(). This test has been done quickly, I'm not totaly confident about its accuracy.
53462163	2020-03-01T13:01:53	mac: Fix gamepad detection
51e9e984	2020-03-01T13:00:50	Fixed whitespace
8a6f1aa5	2020-03-01T12:58:50	Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds. Elmar creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar. Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14). Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace: const int maxattempts = 3; int attempt = 0; while (++attempt <= maxattempts) { /* Wait for the transition to complete, so application changes take effect properly (e.g. setting the window size, etc.) / const int limit = 10000; int count = 0; while ([data->listener isInFullscreenSpaceTransition]) { if ( ++count == limit ) { / Uh oh, transition isn't completing. Should we assert? / break; } SDL_Delay(1); SDL_PumpEvents(); } if ([data->listener isInFullscreenSpace] == (state ? YES : NO)) break; / Try again, the last attempt was interrupted by user gestures / if (![data->listener setFullscreenSpace:(state ? YES : NO)]) break; / ??? */ } One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user. Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs. Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself. Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around. Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first. I can unfortunately not provide a minimum example. Best regards, Elmar 0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207 1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401 2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370 3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512 4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692 5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349 6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135 7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36 8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82 9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8 10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322 11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807 12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335 14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463 15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293 16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371 17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997 19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362 20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290 21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23 22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223 23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555 24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118 25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135 26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188 27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546 28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573 29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347 30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614 31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460 32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383 33 com.yasara.View 0x0000000100418e39 mod_main + 815 34 com.yasara.View 0x000000010029ca5d main2 + 5766 35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19
bd5da73a	2020-03-01T12:50:42	Fixed bug 4992 - UWP/WinRT does not set thread priority when using SDL_SetThreadPriority Ethan Lee Attached is a diff that I used to get SetThreadPriority working locally. I still have no idea what the minimum SDK version is since Microsoft never documented it, but it's worth pointing out that they're much more aggressive about using the latest VS and UWP SDK anyway (for example, an updated Xbox is no longer compatible with VS2017, and updates are required to have a network connection of any kind).
1af31a26	2020-02-27T13:53:32	Fixed trying to handle the HORI Wireless Switch Pad when connected via USB
20d67446	2020-02-27T09:33:32	Xbox One controller rumble doesn't need synchronization if you use a packet counter of 0
2cd88ddf	2020-02-27T09:32:03	Temporarily disabled NEON optimizations added for bug 4365 The ABGR to ARGB blit results in an empty surface, this needs to be looked at.
9013c916	2020-02-27T08:20:34	Fixed bug 5005 - warnings in kmsdrm Malte Kie?ling At the moment i get following warnings from kmsdrm: * in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces is return type int, but thats never returned or checked against * in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces the variable viddata is not used * in SDL_kmsdrmopengles.c KMSDRM_GLES_LoadLibrary a cast to NativeDisplayType is missing I attached a patch for them :)
7f26ff23	2020-02-27T08:18:20	Fixed bug 4987 - Can't build on MinGW a recent state (15'th February, 2020): conflicting types
cbd1a2f7	2020-02-25T14:52:03	cmake: Forgot to add this file to revision control. Fixes Bugzilla #5003.
21a2e0c7	2020-02-25T06:53:51	Fix compilation C90 mixed declarations and code (Thanks Cameron Gutman !)
e2b132ca	2020-02-24T21:57:03	Better fix to set the palette opaque, when there is also a colorkey (see bug 3827)
e3b0713e	2020-02-24T12:07:18	Don't call setPreferredOutputNumberOfChannels on iOS, it breaks audio output
2c9871a4	2020-02-24T10:25:57	Fixed surround sound support on Apple TV
f4857660	2020-02-23T23:07:15	Fix: set to opaque when a palette surface is converted to an alpha format.
bf8aa1ed	2020-02-23T22:38:08	Fix regression: when a palette + colorkey is converted, it needs a blend mode. - Regression of test_1.c of bug 3827, after fix from bug 4798. - Blending is also needed when the palette contains alpha value, but not necessarily colorkey. - Clean up SDL_ConvertColorkeyToAlpha which doesn't seem to need 'ignore_alpha' parameter any-more. (see bug 3827)
094655cf	2020-02-23T14:49:03	cocoa: Make sure wait for button enable can't be infinite.
72316518	2020-02-23T14:48:48	cocoa: Removed a debug printf that was accidentally committed.
9a7c2b22	2020-02-23T09:59:52	Fixed bug 4999 - Palette surface always promoted to alpha (Thanks Cameron Gutman!) MSVC Static analysis: Incorrect alpha_value check in SDL_render.c (see also bug 4425)
dd1d8ab6	2020-02-21T15:52:35	cmake: more proper sdl2-config.cmake work (thanks, Alexander!) Fixes Bugzilla #4970.
be4d488e	2020-02-21T15:51:04	cmake: Backed out changeset 9009d85d3762 This is being replaced by a different patch (see Bugzilla #4970).
4d9e6e5f	2020-02-21T14:50:09	cocoa: When exiting a fullscreen space, wait for window state to normalize. A good metric of this is when the titlebar's "minimize" button is reenabled, which doesn't happen by the time windowDidExitFullscreen triggers. This fixes minimizing a fullscreen window on macOS. Fixes Bugzilla #4177.
8d146363	2020-02-19T08:26:00	Fixed support for third party Xbox 360 wireless controller dongle
44698c49	2020-02-18T01:44:07	dynapi: Fixed build on non-Android platforms.
ad225047	2020-02-17T14:15:47	Added Android SDK conditionals to game controller mappings The Nintendo Switch Pro controller has a different mapping on Android 10 and newer
d7ece7ee	2020-02-17T13:54:45	Made SDL_GetAndroidSDKVersion() available for applications
93b26f17	2020-02-17T16:15:04	opengl: Backed out hg changeset 94f9f40a957f This is the OpenGL line drawing fix for Bugzilla #3182, but there's some disagreement about what the renderers should do here, so I'm backing this out until after 2.0.12 ships, and then we'll reevaluate all the renderer backends to decide what's correct, and make them all work the same.
1b82606e	2020-02-17T16:11:18	x11: Wait a bit in SDL_SetWindowSize() to see if window manager vetoed change. Same idea as the fix for Bugzilla #4646. Fixes Bugzilla #4727.
e7315225	2020-02-17T15:02:37	x11: Don't delay an extra 10ms if we were just going to break out of the loop.
367a8b97	2020-02-17T15:00:02	x11: Don't wait for the window to move if it's already in the place we want it.
1d624aa5	2020-02-16T00:08:36	Further improvements for bug 4128 - CMAKE: Generated target import file contains incorrect include path Mohamed It would be useful to be able to do either `#include "SDL2/SDL.h"` or `#include "SDL.h"`. This patch allows that and adds compatibility with other build systems. It also allows differentiating between SDL1 and SDL2.
4a9dbfef	2020-02-15T16:39:38	Fixed bug 4987 - Can't build on MinGW a recent state: conflicting types Vitaly Novichkov Recent attempt to build a recent HG state of SDL2 via AppVeyor gives the failure: https://ci.appveyor.com/project/Wohlstand/sdl-mixer-x/builds/30821858/job/359gqvypi2f18nok ``` C:\projects\sdl-mixer-x\build-MinGW-w32-MinSizeRel-Win32-VB6-Binding\external\AudioCodecs\src\AudioCodecs-build\external\SDL2\src\SDL2HG\src\dynapi\SDL_dynapi_procs.h:56:29: error: conflicting types for 'SDL_CreateThread' SDL_DYNAPI_PROC(SDL_Thread,SDL_CreateThread,(SDL_ThreadFunction a, const char b, void *c),(a,b,c),return)
dc54add5	2020-02-14T18:21:58	Added some extra permissions and features likely to be used by SDL applications
35704c98	2020-02-14T16:17:17	Fixed bug 4980 - Build fails for SDL_kmsdrm*.c Malte Kie?ling Since https://hg.libsdl.org/SDL/rev/f908bd722523 / bug 4966 i cannot build SDL anymore. The error i get is, essentially, caused by -Werror=declaration-after-statement in SDL_kmsdrmvideo.c and SDL_kmsdrmopengles.c
715f8d42	2020-02-14T16:15:46	Fixed bug 4986 - Memory leak in HIDAPI_JoystickConnected meyraud705 Memory allocated for device->joysticks on line 589 of SDL_hidapijoystick.c is never freed. Also, use memmove because memory is overlapping.
f4e23553	2020-02-14T15:19:34	Fixed audio not coming out of the phone speakers while recording on iOS
922b3dc3	2020-02-14T14:18:12	Fixed re-setting the audio session category when closing an audio device
229c2f8f	2020-02-14T13:37:32	cmake: Add PACKAGE_VERSION and SDL2_VERSION to sdl2-config.cmake.in Fixes Bugzilla #4970.
d1df3437	2020-02-14T13:17:18	x11: SDL_SetWindowPosition should try to wait for the window manager. Wait up to 100 milliseconds, since the window manager might alter or outright veto the window change...or not respond at all. In a well-functioning system, though, this should help make sure that SDL_SetWindowPosition's results match reality. Fixes Bugzilla #4646.
7ad77bcc	2020-02-14T01:08:21	wayland: Don't force the window into OpenGL mode if we want Vulkan.
a77a890d	2020-02-14T00:58:36	wayland: Don't delay pending surface resize handling on Vulkan. OpenGL apparently needs to not do any drawing between wl_egl_window_resize and eglSwapBuffers, but Vulkan apps don't use SDL to present, so they never call into an equivalent of SDL_GL_SwapWindow where our Wayland code was handling pending resize work. Fixes Bugzilla #4722.
14bf532d	2020-02-13T16:10:52	Fixed opening audio on Android from the Steam Link shell activity
033aa51d	2020-02-13T22:58:04	testfilesystem: Don't exit the application if SDL_GetBasePath isn't supported
8f1a916a	2020-02-13T20:50:47	Add basic support for compiling on RISC OS
b4312864	2020-02-13T10:19:05	Resolved conflict and added Android_JNI_RequestPermission()
e261bd42	2020-02-12T12:26:27	Improved fix for bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
afb70f26	2020-02-12T13:09:38	test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility. Fixes Bugzilla #4975.
0a6d80ab	2020-02-12T13:08:29	mac: Wait a bit before activating app at startup. This is obnoxious and wrong, but the patch that activates the Dock before activating the app fixes the _menu_ not responding on Catalina, but the first window created by the app won't have keyboard focus without a small delay inserted. This obviously needs a better solution, but it gets it limping along correctly for now.
6fe6946a	2020-02-11T21:19:05	Fixed relative mode mouse events stopping if you click on the title bar
6ec14b7f	2020-02-11T16:23:43	Fixed iOS and Android build
4bb95e84	2020-02-11T16:14:02	Implemented OpenSL-ES audio recording on Android
fe8ce66b	2020-02-11T10:35:14	Attempt to make version detection safe for Mac OS X < 10.10
52b410ab	2020-02-11T10:21:31	Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15 sjordan We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors. We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case. We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time. We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not. We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case. I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that. ... Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen: /* Hack to fix origin on Mac OS X 10.4 */ NSRect screenRect = [[nswindow screen] frame]; if (screenRect.size.height >= 1.0f) { rect.origin.y += (screenRect.size.height - rect.size.height); } If we comment this one out our game and testdraw2 do behave correctly. It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later). We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions). More info: consider the line NSRect screenRect = [[nswindow screen] frame]; in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise. On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window. What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result? Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.
c31727c7	2020-02-11T10:08:22	Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work The problem here was calling ClipCursor() continuously in a tight loop. Fixed by only calling ClipCursor() if the clip area needs to be updated.
668276fe	2020-02-11T09:41:55	Don't add a frame to borderless windows. It was done to allow hotkey resizing of borderless windows, but Windows will sometimes draw it, regardless of our WM_* message handling. See bug 4466 for more details.
f867cebb	2020-02-11T08:36:13	Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys Alex Denisov When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events. Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++: WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly. With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).
232b7fee	2020-02-11T08:26:46	Make it possible for the application to use different C runtime begin/end thread functions
9feabd35	2020-02-11T08:01:44	Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.
4378fcd9	2020-02-10T23:48:06	wayland: Fix building with -fno-common (which is now the default in GCC 10). Fixes Bugzilla #4957.
d55f47d5	2020-02-10T13:59:05	Fixed compile warning
cbc65ce8	2020-02-10T13:56:53	src/core/linux/SDL_threadprio.c: fix build without threads Add an include on SDL_error.h to avoid the following build failure without threads: /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: build/.libs/SDL_threadprio.o: in function `SDL_LinuxSetThreadPriority_REAL': SDL_threadprio.c:(.text+0x0): undefined reference to `SDL_Unsupported' Fixes: - http://autobuild.buildroot.org/results/7f7712c5bd47de4a3fcec1e0d0526fd5a3ecd532 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
ed10d947	2020-02-10T12:53:54	opengl: Build out full GL_LINES and respect the diamond-exit rule. Likewise for the GLES1 and GLES2 renderers. This solves the missing pixel at the end of a line and removes all the heuristics for various platforms/drivers. It's possible we could still use GL_LINE_STRIP with this and save some vertex buffer space, assuming this doesn't upset some driver somewhere, but this seems to be a clean fix that makes the GL renderers match the software renderer output. Diamond-exit rule explanation: http://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html Fixes Bugzilla #3182.
13155b35	2020-02-10T09:42:53	The scissor rect needs to be updated when the viewport changes in the Metal renderer
3e935aec	2020-02-09T11:44:22	Fixed bug 4966 - KMSDRM: Add dynamic modeset support Anthony Pesch * Remove triple buffering support. As far as I can tell, this goes against the libdrm API; the EGL implementations themselves control the buffering. Removing it isn't absolutely necessary as it seemingly works on the Pi at least, but I noticed this while doing my work and explained my reasoning in the commit. * Replace the crtc_ready logic which allocates an extra bo to perform the initial CRTC configuration (which is required before calling drmModePageFlip) with a call to drmModeSetCrtc after the front and back buffers are allocated, avoiding this allocation. * Standardized the SDL_Data variable names and null checks to improve readability. Given that there were duplicate fields in each SDL_Data structure, having generic names such as "data" at times was very confusing. * Removed unused fields from the SDL_Data structures and moves all display related fields out of SDL_VideoData and into SDL_DisplayData. Not required since the code only supports a single display right now, but this was helpful in reading and understanding the code initially. Implement KMSDRM_GetDisplayModes / KMSDRM_SetDisplayMode to provide dynamic modeset support. These changes have been tested on a Raspberry Pi 4 and a Dell XPS laptop with an HD 520. As an update, I went back over the triple buffer changes and left them in. I didn't entirely get the code originally, I had just seen it calling KMSDRM_gbm_surface_lock_front_buffer twice for a single swap and had removed it because I was paranoid of bugs stemming from it while working on the modeset changes. I've made a few small changes to the logic that had thrown me off originally and rebased the changes: * The condition wrapping the call to release buffer was incorrect. * The first call to KMSDRM_gbm_surface_lock_front_buffer has been removed. I don't understand why it existed. * Added additional comments describing what was going on in the code (as it does fix the buffer release pattern of the original code before it).
80cf4f07	2020-02-08T19:34:51	test: Improved detection of OpenGL support
64c58b9f	2020-02-07T20:20:37	Fixed NullPointerException
e5e54169	2020-02-07T20:19:32	Removed VID/PID 0x1532/0x0037, which was listed in the Linux kernel as a Razer Sabertooth, because at least one variant of the Razer DeathAdder mouse shows up with this VID/PID. Specifically the Razer DeathAdder 2013 has this VID/PID
833f76ab	2020-02-07T11:49:56	Fixed bug 4968 - NULL passed to memcpy in WriteProprietary in SDL_hidapi_switch.c meyraud705 In SDL_hidapi_switch.c line 443: Function BTrySetupUSB call WriteProprietary with pBuf=NULL and ucLen=0 line 376: WriteProprietary check its input (!pBuf && ucLen > 0) \|\| ucLen > sizeof(packet.rgucProprietaryData): ucLen is 0 so it passes line 382: WriteProprietary call memcpy with pBuf=NULL
dd0ebfdf	2020-02-07T11:45:32	Use the triggers to test rumble for more fine grained vibration feedback
8ba77b35	2020-02-07T11:44:57	Use the asynchronous HIDAPI rumble code for Nintendo Switch Pro controllers
81256207	2020-02-07T11:02:34	Update for bug 4923 - Calling SDL_GameControllerRumble() often takes 8 ms meyraud705 Dualshock4 on bluetooth need 78 bytes for the rumble data while SDL_HIDAPI_RumbleRequest can only hold 64 bytes. 'volatile' is not meant for thread synchronization. The list of rumble request could grow infinitely if user call SDL_JoystickRumble too much. The documentation says "Each call to this function cancels any previous rumble effect", so overwriting pending request seem like a good idea.
d88f3f52	2020-02-05T13:16:17	macOS: fix crash if and when joystick-init-on-add fails
a199cb89	2020-02-05T09:29:46	Updated the Android Xbox One Wireless Controller mapping for the latest Xbox controller firmware update
dc1d3c29	2020-02-04T18:36:23	Catch both PS3 and PS4 motion controls and don't treat them as a game controller
1d1a35ef	2020-02-04T16:05:39	Fixed Visual Studio build
1bd12026	2020-02-04T15:42:49	Added SDL_hidapi_rumble.c to the macOS, iOS and tvOS builds
7c7ae002	2020-02-04T15:35:01	Added SDL_hidapi_rumble.c to the Visual Studio project
02108cf7	2020-02-04T15:27:25	Added missing files from previous commit
1684606f	2020-02-04T15:26:56	Fixed long delay on main thread caused by blocking rumble writes in HIDAPI drivers There is now a thread that handles all HIDAPI rumble requests and a lock that guarantees that we're not reading and writing the device at the same time.
6efebf17	2020-02-04T12:48:53	Moved rumble expiration to the main joystick handling level, and prevent sending the driver layer duplicate rumble requests.
582f5706	2020-02-04T16:46:22	Improved CPU detection on ARM platforms
976eee77	2020-02-04T07:23:44	Correct joystick hat indexes on linux The index and indices were swapped; Which is fine as long as there are no gaps in the ABS_HAT* event availability but otherwise things do get confused. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
d19006c5	2020-02-03T16:38:07	Fixed bug 4965 - Update the .hgignore file Cameron Cawley This adds a number of files used by the build systems to the .hgignore file. Most of them are for CMake, but there are other additions as well.
ca2186a2	2020-02-03T16:34:33	Fixed bug 4758 - hgignore clion build artifacts Malte clion builds into cmake-build-debug, cmake-build-release etc. by default. Also, it creates the .idea forlder in wich it places some (mostly local) config. Since SDL is perfectly buildable from within the IDE, i think it'd be nice to have the build and ide artifacts ignored by hg.
4b585e75	2020-02-03T08:06:52	Fixed bug 4833 - Use EGL for X11? Martin Fiedler To be precise, this is about desktop OpenGL on X11. For OpenGL ES, EGL is already used (as it's the only way to get an OpenGL ES context), as Sylvain noted above. To shine some light on why this is needed: In 99% of all cases, using GLX on X11 is fine, even though it's effectively deprecated in favor of EGL [1]. However, there's at least one use case that requires the OpenGL context being created with EGL instead of GLX, and that's DRM_PRIME interoperability: The function glEGLImageTargetTexture2DOES simply doesn't work with GLX. (Currently, Mesa actually crashes when trying that.) Some example code: https://gist.github.com/kajott/d1b29c613be30893c855621edd1f212e Runs on Intel and open-source AMD drivers just fine (others unconfirmed), but with #define USE_EGL 0 (i.e. forcing it to GLX), it crashes. The same happens when using SDL for window and context creation. The good news is that most of the pieces for EGL support on X11 are already in place: SDL_egl.c is pretty complete (and used for desktop OpenGL on Wayland, for example), and SDL_x11opengl.c has the aforementioned OpenGL-ES-on-EGL support. However, when it comes to desktop OpenGL, it's hardcoded to fall back to GLX. I'm not advocating to make EGL the default for desktop OpenGL on X11; don't fix what ain't broken. But something like an SDL_HINT_VIDEO_X11_FORCE_EGL would be very appreciated to make use cases like the above work with SDL. [1] source: Eric Anholt, major Linux graphics stack developer, 7 years ago already - see last paragraph of https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI
67f44788	2020-02-03T00:57:12	Fixed bug 4917 - Wayland: handle discrete pointer axis events Luis Caceres The current handling of Wayland mouse pointer events only handles wl_pointer.axis events, which, according to the Wayland documentation, deal with mouse wheel scroll events on a continuous scale. While this is reasonable for some input sources (e.g. touchpad two-finger scrolling), it is not for mouse wheel clicks which generate wl_pointer.axis events with large deltas. This patch adds handling for wl_pointer.axis_discrete and wl_pointer.frame events and prefers to report SDL_MouseWheelEvent in discrete units if they are available. This means that for mouse wheel scrolling we count in clicks, but for touchpad two-finger scrolling we still use whatever units Wayland uses. This behaviour is closer to that of the X11 backend. Since these events are only available since version 5 of the wl_seat interface, this patch also checks for this and falls back to the previous behaviour if its not available. I also had to add definitions for some of the pointer and keyboard events specified in versions 2-5 but these are just stubs and do nothing.

f00ddd0a

2020-03-02T11:39:44

Updated WhatsNew.txt with SDL 2.0.12 release notes

25061816

2020-03-02T10:58:08

Fixed compile warning

eb19631a

2020-03-02T10:57:57

This controller firmware is supported on Windows, and is covered by the Bluetooth check on Mac OSX

49564c8b

2020-03-02T10:47:48

Added support for the PDP Victrix Pro FS with Touch Pad for PS4

4572dd2a

2020-03-02T10:37:28

Fixed bug 4854 - Add a way to extend the values in controller_type.h Added a hint SDL_HINT_GAMECONTROLLERTYPE to allow overriding the built-in controller type database

27f346a0

2020-03-02T09:46:37

Fixed compile warning

339612d5

2020-03-02T09:35:12

ControllerList: add support for Victrix Pro FS w/ Touchpad for PS4

52be6633

2020-03-02T09:35:09

Use SDL math functions in Steam Controller support

756d2073

2020-03-02T09:26:12

Updated the HIDAPI Xbox One driver with support for Bluetooth Xbox One controllers

997f3e9e

2020-03-02T09:03:55

Fixed build warnings

11a84e4f

2020-03-01T18:16:15

Make sure hidapi is built for the release DMG

bebc4867

2020-03-01T17:53:30

We already have a hidapi implementation for Windows, we don't need libusb

74ed2156

2020-03-01T14:58:16

Updated version to 2.0.12 for release candidate build

6590d078

2020-03-01T14:52:49

Fixed bug 4996 - Mac: XBoxOne Bluetooth rumble isn't working rofferom I have an annoying issue on MacOS about XBoxOne Bluetooth rumble (Vendor: 0x045e, Product: 0x02fd). When 360controller is installed, rumble is working correctly. However, Bluetooth rumble isn't working at all, with or without 360controller installed (although it is working with Chrome + https://html5gamepad.com). I looked at the code, and it seems that XBox controllers are managed in MacOS in this file: SDL_hidapi_xbox360.c. The XBoxOne file is disabled for MacOS in SDL_hidjoystick_c.h. The function HIDAPI_DriverXbox360_Rumble() is called correctly, and hid_write() returns no error. I have tried a stupid test. I took the rumble packet from 360controller: https://github.com/360Controller/360Controller/blob/ec4e88eb2d2535e9b32561c702f42fb22b0a7f99/XBOBTFF/FFDriver.cpp#L620. With the patch I have attached, I manage to have rumble working on Bluetooth (with some stupid vibration level, but it proves it can if the packet is changed). But it breaks the USB rumble with 360controller. A comment in the function makes an explicit reference to 360controller, I think that's why I have broken this specific usecase. I don't know what is the correct way to fix this, but it seems that the current implementation has a missing case for Bluetooth support. Note that I also tested master this morning, and I have another issue: if (!device->ffservice) { return SDL_Unsupported(); } test fails in DARWIN_JoystickRumble(). This test has been done quickly, I'm not totaly confident about its accuracy.

53462163

2020-03-01T13:01:53

mac: Fix gamepad detection

51e9e984

2020-03-01T13:00:50

Fixed whitespace

8a6f1aa5

2020-03-01T12:58:50

Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds. Elmar creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar. Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14). Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace: const int maxattempts = 3; int attempt = 0; while (++attempt <= maxattempts) { /* Wait for the transition to complete, so application changes take effect properly (e.g. setting the window size, etc.) */ const int limit = 10000; int count = 0; while ([data->listener isInFullscreenSpaceTransition]) { if ( ++count == limit ) { /* Uh oh, transition isn't completing. Should we assert? */ break; } SDL_Delay(1); SDL_PumpEvents(); } if ([data->listener isInFullscreenSpace] == (state ? YES : NO)) break; /* Try again, the last attempt was interrupted by user gestures */ if (![data->listener setFullscreenSpace:(state ? YES : NO)]) break; /* ??? */ } One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user. Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs. Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself. Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around. Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first. I can unfortunately not provide a minimum example. Best regards, Elmar 0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207 1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401 2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370 3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512 4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692 5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349 6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135 7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36 8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82 9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8 10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322 11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807 12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335 14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463 15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293 16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371 17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997 19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362 20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290 21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23 22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223 23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555 24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118 25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135 26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188 27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546 28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573 29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347 30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614 31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460 32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383 33 com.yasara.View 0x0000000100418e39 mod_main + 815 34 com.yasara.View 0x000000010029ca5d main2 + 5766 35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19

bd5da73a

2020-03-01T12:50:42

Fixed bug 4992 - UWP/WinRT does not set thread priority when using SDL_SetThreadPriority Ethan Lee Attached is a diff that I used to get SetThreadPriority working locally. I still have no idea what the minimum SDK version is since Microsoft never documented it, but it's worth pointing out that they're much more aggressive about using the latest VS and UWP SDK anyway (for example, an updated Xbox is no longer compatible with VS2017, and updates are required to have a network connection of any kind).

1af31a26

2020-02-27T13:53:32

Fixed trying to handle the HORI Wireless Switch Pad when connected via USB

20d67446

2020-02-27T09:33:32

Xbox One controller rumble doesn't need synchronization if you use a packet counter of 0

2cd88ddf

2020-02-27T09:32:03

Temporarily disabled NEON optimizations added for bug 4365 The ABGR to ARGB blit results in an empty surface, this needs to be looked at.

9013c916

2020-02-27T08:20:34

Fixed bug 5005 - warnings in kmsdrm Malte Kie?ling At the moment i get following warnings from kmsdrm: * in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces is return type int, but thats never returned or checked against * in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces the variable viddata is not used * in SDL_kmsdrmopengles.c KMSDRM_GLES_LoadLibrary a cast to NativeDisplayType is missing I attached a patch for them :)

7f26ff23

2020-02-27T08:18:20

Fixed bug 4987 - Can't build on MinGW a recent state (15'th February, 2020): conflicting types

cbd1a2f7

2020-02-25T14:52:03

cmake: Forgot to add this file to revision control. Fixes Bugzilla #5003.

21a2e0c7

2020-02-25T06:53:51

Fix compilation C90 mixed declarations and code (Thanks Cameron Gutman !)

e2b132ca

2020-02-24T21:57:03

Better fix to set the palette opaque, when there is also a colorkey (see bug 3827)

e3b0713e

2020-02-24T12:07:18

Don't call setPreferredOutputNumberOfChannels on iOS, it breaks audio output

2c9871a4

2020-02-24T10:25:57

Fixed surround sound support on Apple TV

f4857660

2020-02-23T23:07:15

Fix: set to opaque when a palette surface is converted to an alpha format.

bf8aa1ed

2020-02-23T22:38:08

Fix regression: when a palette + colorkey is converted, it needs a blend mode. - Regression of test_1.c of bug 3827, after fix from bug 4798. - Blending is also needed when the palette contains alpha value, but not necessarily colorkey. - Clean up SDL_ConvertColorkeyToAlpha which doesn't seem to need 'ignore_alpha' parameter any-more. (see bug 3827)

094655cf

2020-02-23T14:49:03

cocoa: Make sure wait for button enable can't be infinite.

72316518

2020-02-23T14:48:48

cocoa: Removed a debug printf that was accidentally committed.

9a7c2b22

2020-02-23T09:59:52

Fixed bug 4999 - Palette surface always promoted to alpha (Thanks Cameron Gutman!) MSVC Static analysis: Incorrect alpha_value check in SDL_render.c (see also bug 4425)

dd1d8ab6

2020-02-21T15:52:35

cmake: more proper sdl2-config.cmake work (thanks, Alexander!) Fixes Bugzilla #4970.

be4d488e

2020-02-21T15:51:04

cmake: Backed out changeset 9009d85d3762 This is being replaced by a different patch (see Bugzilla #4970).

4d9e6e5f

2020-02-21T14:50:09

cocoa: When exiting a fullscreen space, wait for window state to normalize. A good metric of this is when the titlebar's "minimize" button is reenabled, which doesn't happen by the time windowDidExitFullscreen triggers. This fixes minimizing a fullscreen window on macOS. Fixes Bugzilla #4177.

8d146363

2020-02-19T08:26:00

Fixed support for third party Xbox 360 wireless controller dongle

44698c49

2020-02-18T01:44:07

dynapi: Fixed build on non-Android platforms.

ad225047

2020-02-17T14:15:47

Added Android SDK conditionals to game controller mappings The Nintendo Switch Pro controller has a different mapping on Android 10 and newer

d7ece7ee

2020-02-17T13:54:45

Made SDL_GetAndroidSDKVersion() available for applications

93b26f17

2020-02-17T16:15:04

opengl: Backed out hg changeset 94f9f40a957f This is the OpenGL line drawing fix for Bugzilla #3182, but there's some disagreement about what the renderers should do here, so I'm backing this out until after 2.0.12 ships, and then we'll reevaluate all the renderer backends to decide what's correct, and make them all work the same.

1b82606e

2020-02-17T16:11:18

x11: Wait a bit in SDL_SetWindowSize() to see if window manager vetoed change. Same idea as the fix for Bugzilla #4646. Fixes Bugzilla #4727.

e7315225

2020-02-17T15:02:37

x11: Don't delay an extra 10ms if we were just going to break out of the loop.

367a8b97

2020-02-17T15:00:02

x11: Don't wait for the window to move if it's already in the place we want it.

1d624aa5

2020-02-16T00:08:36

Further improvements for bug 4128 - CMAKE: Generated target import file contains incorrect include path Mohamed It would be useful to be able to do either `#include "SDL2/SDL.h"` or `#include "SDL.h"`. This patch allows that and adds compatibility with other build systems. It also allows differentiating between SDL1 and SDL2.

4a9dbfef

2020-02-15T16:39:38

Fixed bug 4987 - Can't build on MinGW a recent state: conflicting types Vitaly Novichkov Recent attempt to build a recent HG state of SDL2 via AppVeyor gives the failure: https://ci.appveyor.com/project/Wohlstand/sdl-mixer-x/builds/30821858/job/359gqvypi2f18nok ``` C:\projects\sdl-mixer-x\build-MinGW-w32-MinSizeRel-Win32-VB6-Binding\external\AudioCodecs\src\AudioCodecs-build\external\SDL2\src\SDL2HG\src\dynapi\SDL_dynapi_procs.h:56:29: error: conflicting types for 'SDL_CreateThread' SDL_DYNAPI_PROC(SDL_Thread*,SDL_CreateThread,(SDL_ThreadFunction a, const char *b, void *c),(a,b,c),return)

dc54add5

2020-02-14T18:21:58

Added some extra permissions and features likely to be used by SDL applications

35704c98

2020-02-14T16:17:17

Fixed bug 4980 - Build fails for SDL_kmsdrm*.c Malte Kie?ling Since https://hg.libsdl.org/SDL/rev/f908bd722523 / bug 4966 i cannot build SDL anymore. The error i get is, essentially, caused by -Werror=declaration-after-statement in SDL_kmsdrmvideo.c and SDL_kmsdrmopengles.c

715f8d42

2020-02-14T16:15:46

Fixed bug 4986 - Memory leak in HIDAPI_JoystickConnected meyraud705 Memory allocated for device->joysticks on line 589 of SDL_hidapijoystick.c is never freed. Also, use memmove because memory is overlapping.

f4e23553

2020-02-14T15:19:34

Fixed audio not coming out of the phone speakers while recording on iOS

922b3dc3

2020-02-14T14:18:12

Fixed re-setting the audio session category when closing an audio device

229c2f8f

2020-02-14T13:37:32

cmake: Add PACKAGE_VERSION and SDL2_VERSION to sdl2-config.cmake.in Fixes Bugzilla #4970.

d1df3437

2020-02-14T13:17:18

x11: SDL_SetWindowPosition should try to wait for the window manager. Wait up to 100 milliseconds, since the window manager might alter or outright veto the window change...or not respond at all. In a well-functioning system, though, this should help make sure that SDL_SetWindowPosition's results match reality. Fixes Bugzilla #4646.

7ad77bcc

2020-02-14T01:08:21

wayland: Don't force the window into OpenGL mode if we want Vulkan.

a77a890d

2020-02-14T00:58:36

wayland: Don't delay pending surface resize handling on Vulkan. OpenGL apparently needs to not do any drawing between wl_egl_window_resize and eglSwapBuffers, but Vulkan apps don't use SDL to present, so they never call into an equivalent of SDL_GL_SwapWindow where our Wayland code was handling pending resize work. Fixes Bugzilla #4722.

14bf532d

2020-02-13T16:10:52

Fixed opening audio on Android from the Steam Link shell activity

033aa51d

2020-02-13T22:58:04

testfilesystem: Don't exit the application if SDL_GetBasePath isn't supported

8f1a916a

2020-02-13T20:50:47

Add basic support for compiling on RISC OS

b4312864

2020-02-13T10:19:05

Resolved conflict and added Android_JNI_RequestPermission()

e261bd42

2020-02-12T12:26:27

Improved fix for bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work

afb70f26

2020-02-12T13:09:38

test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility. Fixes Bugzilla #4975.

0a6d80ab

2020-02-12T13:08:29

mac: Wait a bit before activating app at startup. This is obnoxious and wrong, but the patch that activates the Dock before activating the app fixes the _menu_ not responding on Catalina, but the first window created by the app won't have keyboard focus without a small delay inserted. This obviously needs a better solution, but it gets it limping along correctly for now.

6fe6946a

2020-02-11T21:19:05

Fixed relative mode mouse events stopping if you click on the title bar

6ec14b7f

2020-02-11T16:23:43

Fixed iOS and Android build

4bb95e84

2020-02-11T16:14:02

Implemented OpenSL-ES audio recording on Android

fe8ce66b

2020-02-11T10:35:14

Attempt to make version detection safe for Mac OS X < 10.10

52b410ab

2020-02-11T10:21:31

Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15 sjordan We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors. We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case. We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time. We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not. We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case. I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that. ... Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen: /* Hack to fix origin on Mac OS X 10.4 */ NSRect screenRect = [[nswindow screen] frame]; if (screenRect.size.height >= 1.0f) { rect.origin.y += (screenRect.size.height - rect.size.height); } If we comment this one out our game and testdraw2 do behave correctly. It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later). We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions). More info: consider the line NSRect screenRect = [[nswindow screen] frame]; in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise. On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window. What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result? Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.

c31727c7

2020-02-11T10:08:22

Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work The problem here was calling ClipCursor() continuously in a tight loop. Fixed by only calling ClipCursor() if the clip area needs to be updated.

668276fe

2020-02-11T09:41:55

Don't add a frame to borderless windows. It was done to allow hotkey resizing of borderless windows, but Windows will sometimes draw it, regardless of our WM_* message handling. See bug 4466 for more details.

f867cebb

2020-02-11T08:36:13

Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys Alex Denisov When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events. Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++: WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly. With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).

232b7fee

2020-02-11T08:26:46

Make it possible for the application to use different C runtime begin/end thread functions

9feabd35

2020-02-11T08:01:44

Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.

4378fcd9

2020-02-10T23:48:06

wayland: Fix building with -fno-common (which is now the default in GCC 10). Fixes Bugzilla #4957.

d55f47d5

2020-02-10T13:59:05

Fixed compile warning

cbc65ce8

2020-02-10T13:56:53

src/core/linux/SDL_threadprio.c: fix build without threads Add an include on SDL_error.h to avoid the following build failure without threads: /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: build/.libs/SDL_threadprio.o: in function `SDL_LinuxSetThreadPriority_REAL': SDL_threadprio.c:(.text+0x0): undefined reference to `SDL_Unsupported' Fixes: - http://autobuild.buildroot.org/results/7f7712c5bd47de4a3fcec1e0d0526fd5a3ecd532 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

ed10d947

2020-02-10T12:53:54

opengl: Build out full GL_LINES and respect the diamond-exit rule. Likewise for the GLES1 and GLES2 renderers. This solves the missing pixel at the end of a line and removes all the heuristics for various platforms/drivers. It's possible we could still use GL_LINE_STRIP with this and save some vertex buffer space, assuming this doesn't upset some driver somewhere, but this seems to be a clean fix that makes the GL renderers match the software renderer output. Diamond-exit rule explanation: http://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html Fixes Bugzilla #3182.

13155b35

2020-02-10T09:42:53

The scissor rect needs to be updated when the viewport changes in the Metal renderer

3e935aec

2020-02-09T11:44:22

Fixed bug 4966 - KMSDRM: Add dynamic modeset support Anthony Pesch * Remove triple buffering support. As far as I can tell, this goes against the libdrm API; the EGL implementations themselves control the buffering. Removing it isn't absolutely necessary as it seemingly works on the Pi at least, but I noticed this while doing my work and explained my reasoning in the commit. * Replace the crtc_ready logic which allocates an extra bo to perform the initial CRTC configuration (which is required before calling drmModePageFlip) with a call to drmModeSetCrtc after the front and back buffers are allocated, avoiding this allocation. * Standardized the SDL_*Data variable names and null checks to improve readability. Given that there were duplicate fields in each SDL_*Data structure, having generic names such as "data" at times was very confusing. * Removed unused fields from the SDL_*Data structures and moves all display related fields out of SDL_VideoData and into SDL_DisplayData. Not required since the code only supports a single display right now, but this was helpful in reading and understanding the code initially. * Implement KMSDRM_GetDisplayModes / KMSDRM_SetDisplayMode to provide dynamic modeset support. These changes have been tested on a Raspberry Pi 4 and a Dell XPS laptop with an HD 520. As an update, I went back over the triple buffer changes and left them in. I didn't entirely get the code originally, I had just seen it calling KMSDRM_gbm_surface_lock_front_buffer twice for a single swap and had removed it because I was paranoid of bugs stemming from it while working on the modeset changes. I've made a few small changes to the logic that had thrown me off originally and rebased the changes: * The condition wrapping the call to release buffer was incorrect. * The first call to KMSDRM_gbm_surface_lock_front_buffer has been removed. I don't understand why it existed. * Added additional comments describing what was going on in the code (as it does fix the buffer release pattern of the original code before it).

80cf4f07

2020-02-08T19:34:51

test: Improved detection of OpenGL support

64c58b9f

2020-02-07T20:20:37

Fixed NullPointerException

e5e54169

2020-02-07T20:19:32

Removed VID/PID 0x1532/0x0037, which was listed in the Linux kernel as a Razer Sabertooth, because at least one variant of the Razer DeathAdder mouse shows up with this VID/PID. Specifically the Razer DeathAdder 2013 has this VID/PID

833f76ab

2020-02-07T11:49:56

Fixed bug 4968 - NULL passed to memcpy in WriteProprietary in SDL_hidapi_switch.c meyraud705 In SDL_hidapi_switch.c line 443: Function BTrySetupUSB call WriteProprietary with pBuf=NULL and ucLen=0 line 376: WriteProprietary check its input (!pBuf && ucLen > 0) || ucLen > sizeof(packet.rgucProprietaryData): ucLen is 0 so it passes line 382: WriteProprietary call memcpy with pBuf=NULL

dd0ebfdf

2020-02-07T11:45:32

Use the triggers to test rumble for more fine grained vibration feedback

8ba77b35

2020-02-07T11:44:57

Use the asynchronous HIDAPI rumble code for Nintendo Switch Pro controllers

81256207

2020-02-07T11:02:34

Update for bug 4923 - Calling SDL_GameControllerRumble() often takes 8 ms meyraud705 Dualshock4 on bluetooth need 78 bytes for the rumble data while SDL_HIDAPI_RumbleRequest can only hold 64 bytes. 'volatile' is not meant for thread synchronization. The list of rumble request could grow infinitely if user call SDL_JoystickRumble too much. The documentation says "Each call to this function cancels any previous rumble effect", so overwriting pending request seem like a good idea.

d88f3f52

2020-02-05T13:16:17

macOS: fix crash if and when joystick-init-on-add fails

a199cb89

2020-02-05T09:29:46

Updated the Android Xbox One Wireless Controller mapping for the latest Xbox controller firmware update

dc1d3c29

2020-02-04T18:36:23

Catch both PS3 and PS4 motion controls and don't treat them as a game controller

1d1a35ef

2020-02-04T16:05:39

Fixed Visual Studio build

1bd12026

2020-02-04T15:42:49

Added SDL_hidapi_rumble.c to the macOS, iOS and tvOS builds

7c7ae002

2020-02-04T15:35:01

Added SDL_hidapi_rumble.c to the Visual Studio project

02108cf7

2020-02-04T15:27:25

Added missing files from previous commit

1684606f

2020-02-04T15:26:56

Fixed long delay on main thread caused by blocking rumble writes in HIDAPI drivers There is now a thread that handles all HIDAPI rumble requests and a lock that guarantees that we're not reading and writing the device at the same time.

6efebf17

2020-02-04T12:48:53

Moved rumble expiration to the main joystick handling level, and prevent sending the driver layer duplicate rumble requests.

582f5706

2020-02-04T16:46:22

Improved CPU detection on ARM platforms

976eee77

2020-02-04T07:23:44

Correct joystick hat indexes on linux The index and indices were swapped; Which is fine as long as there are no gaps in the ABS_HAT* event availability but otherwise things do get confused. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

d19006c5

2020-02-03T16:38:07

Fixed bug 4965 - Update the .hgignore file Cameron Cawley This adds a number of files used by the build systems to the .hgignore file. Most of them are for CMake, but there are other additions as well.

ca2186a2

2020-02-03T16:34:33

Fixed bug 4758 - hgignore clion build artifacts Malte clion builds into cmake-build-debug, cmake-build-release etc. by default. Also, it creates the .idea forlder in wich it places some (mostly local) config. Since SDL is perfectly buildable from within the IDE, i think it'd be nice to have the build and ide artifacts ignored by hg.

4b585e75

2020-02-03T08:06:52

Fixed bug 4833 - Use EGL for X11? Martin Fiedler To be precise, this is about *desktop OpenGL* on X11. For OpenGL ES, EGL is already used (as it's the only way to get an OpenGL ES context), as Sylvain noted above. To shine some light on why this is needed: In 99% of all cases, using GLX on X11 is fine, even though it's effectively deprecated in favor of EGL [1]. However, there's at least one use case that *requires* the OpenGL context being created with EGL instead of GLX, and that's DRM_PRIME interoperability: The function glEGLImageTargetTexture2DOES simply doesn't work with GLX. (Currently, Mesa actually crashes when trying that.) Some example code: https://gist.github.com/kajott/d1b29c613be30893c855621edd1f212e Runs on Intel and open-source AMD drivers just fine (others unconfirmed), but with #define USE_EGL 0 (i.e. forcing it to GLX), it crashes. The same happens when using SDL for window and context creation. The good news is that most of the pieces for EGL support on X11 are already in place: SDL_egl.c is pretty complete (and used for desktop OpenGL on Wayland, for example), and SDL_x11opengl.c has the aforementioned OpenGL-ES-on-EGL support. However, when it comes to desktop OpenGL, it's hardcoded to fall back to GLX. I'm not advocating to make EGL the default for desktop OpenGL on X11; don't fix what ain't broken. But something like an SDL_HINT_VIDEO_X11_FORCE_EGL would be very appreciated to make use cases like the above work with SDL. [1] source: Eric Anholt, major Linux graphics stack developer, 7 years ago already - see last paragraph of https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI

67f44788

2020-02-03T00:57:12

Fixed bug 4917 - Wayland: handle discrete pointer axis events Luis Caceres The current handling of Wayland mouse pointer events only handles wl_pointer.axis events, which, according to the Wayland documentation, deal with mouse wheel scroll events on a continuous scale. While this is reasonable for some input sources (e.g. touchpad two-finger scrolling), it is not for mouse wheel clicks which generate wl_pointer.axis events with large deltas. This patch adds handling for wl_pointer.axis_discrete and wl_pointer.frame events and prefers to report SDL_MouseWheelEvent in discrete units if they are available. This means that for mouse wheel scrolling we count in clicks, but for touchpad two-finger scrolling we still use whatever units Wayland uses. This behaviour is closer to that of the X11 backend. Since these events are only available since version 5 of the wl_seat interface, this patch also checks for this and falls back to the previous behaviour if its not available. I also had to add definitions for some of the pointer and keyboard events specified in versions 2-5 but these are just stubs and do nothing.

kc3-lang/SDL

Log