libs/SDL2/docs/README-emscripten.md

-Emscripten
-================================================================================
+# Emscripten
+
+(This documentation is not very robust; we will update and expand this later.)
+
+## A quick note about audio
+
+Modern web browsers will not permit web pages to produce sound before the
+user has interacted with them; this is for several reasons, not the least
+of which being that no one likes when a random browser tab suddenly starts
+making noise and the user has to scramble to figure out which and silence
+it.
+
+To solve this, most browsers will refuse to let a web app use the audio
+subsystem at all before the user has interacted with (clicked on) the page
+in a meaningful way. SDL-based apps also have to deal with this problem; if
+the user hasn't interacted with the page, SDL_OpenAudioDevice will fail.
+
+There are two reasonable ways to deal with this: if you are writing some
+sort of media player thing, where the user expects there to be a volume
+control when you mouseover the canvas, just default that control to a muted
+state; if the user clicks on the control to unmute it, on this first click,
+open the audio device. This allows the media to play at start, the user can
+reasonably opt-in to listening, and you never get access denied to the audio
+device.
+
+Many games do not have this sort of UI, and are more rigid about starting
+audio along with everything else at the start of the process. For these, your
+best bet is to write a little Javascript that puts up a "Click here to play!"
+UI, and upon the user clicking, remove that UI and then call the Emscripten
+app's main() function. As far as the application knows, the audio device was
+available to be opened as soon as the program started, and since this magic
+happens in a little Javascript, you don't have to change your C/C++ code at
+all to make it happen.
+
+Please see the discussion at https://github.com/libsdl-org/SDL/issues/6385
+for some Javascript code to steal for this approach.
+
+
+## Building SDL/emscripten
+
+SDL currently requires at least Emscripten 3.1.35 to build. Newer versions
+are likely to work, as well.
+
 
 Build:
 
     $ mkdir build
     $ cd build
-    $ emconfigure ../configure --host=asmjs-unknown-emscripten --disable-assembly --disable-threads --enable-cpuinfo=false CFLAGS="-O2"
+    $ emconfigure ../configure --host=asmjs-unknown-emscripten --disable-assembly --disable-threads --disable-cpuinfo CFLAGS="-O2"
     $ emmake make
 
 Or with cmake:
@@ -22,8 +63,6 @@ To build one of the tests:
 
 Uses GLES2 renderer or software
 
-tests: https://dl.dropboxusercontent.com/u/17360362/SDL2-em/index.html
-
 Some other SDL2 libraries can be easily built (assuming SDL2 is installed somewhere):
 
 SDL_mixer (http://www.libsdl.org/projects/SDL_mixer/):

libs/SDL2/docs/README-gdk.md

+GDK
+=====
+
+This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
+
+Windows (GDK) and  Xbox One/Xbox Series (GDKX) are supported. Although most of the Xbox code is included in the public SDL source code, NDA access is required for a small number of source files. If you have access to GDKX, these required Xbox files are posted on the GDK forums [here](https://forums.xboxlive.com/questions/130003/).
+
+
+Requirements
+------------
+
+* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
+* Microsoft GDK June 2022 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/June_2022))
+* To publish a package or successfully authenticate a user, you will need to create an app id/configure services in Partner Center. However, for local testing purposes (without authenticating on Xbox Live), the identifiers used by the GDK test programs in the included solution will work.
+
+
+Windows GDK Status
+------
+
+The Windows GDK port supports the full set of Win32 APIs, renderers, controllers, input devices, etc., as the normal Windows x64 build of SDL.
+
+* Additionally, the GDK port adds the following:
+  * Compile-time platform detection for SDL programs. The `__GDK__` is `#define`d on every GDK platform, and the  `__WINGDK__` is `#define`d on Windows GDK, specifically. (This distinction exists because other GDK platforms support a smaller subset of functionality. This allows you to mark code for "any" GDK separate from Windows GDK.)
+  * GDK-specific setup:
+    * Initializing/uninitializing the game runtime, and initializing Xbox Live services
+    * Creating a global task queue and setting it as the default for the process. When running any async operations, passing in `NULL` as the task queue will make the task get added to the global task queue.
+
+  * An implementation on `WinMain` that performs the above GDK setup (you should link against SDL2main.lib, as in Windows x64). If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
+  * Global task queue callbacks are dispatched during `SDL_PumpEvents` (which is also called internally if using `SDL_PollEvent`).
+  * You can get the handle of the global task queue through `SDL_GDKGetTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
+
+* What doesn't work:
+  * Compilation with anything other than through the included Visual C++ solution file
+
+## VisualC-GDK Solution
+
+The included `VisualC-GDK/SDL.sln` solution includes the following targets for the Gaming.Desktop.x64 configuration:
+
+* SDL2 (DLL) - This is the typical SDL2.dll, but for Gaming.Desktop.x64.
+* SDL2main (lib) - This contains a drop-in implementation of `WinMain` that is used as the entry point for GDK programs.
+* tests/testgamecontroller - Standard SDL test program demonstrating controller functionality.
+* tests/testgdk - GDK-specific test program that demonstrates using the global task queue to login a user into Xbox Live.
+  *NOTE*: As of the June 2022 GDK, you cannot test user logins without a valid Title ID and MSAAppId. You will need to manually change the identifiers in the `MicrosoftGame.config` to your valid IDs from Partner Center if you wish to test this.
+* tests/testsprite2 - Standard SDL test program demonstrating sprite drawing functionality.
+
+If you set one of the test programs as a startup project, you can run it directly from Visual Studio.
+
+Windows GDK Setup, Detailed Steps
+---------------------
+
+These steps assume you already have a game using SDL that runs on Windows x64 along with a corresponding Visual Studio solution file for the x64 version. If you don't have this, it's easiest to use one of the test program vcxproj files in the `VisualC-GDK` directory as a starting point, though you will still need to do most of the steps below.
+
+### 1. Add a Gaming.Desktop.x64 Configuration ###
+
+In your game's existing Visual Studio Solution, go to Build > Configuration Manager. From the "Active solution platform" drop-down select "New...". From the drop-down list, select Gaming.Desktop.x64 and copy the settings from the x64 configuration.
+
+### 2. Build SDL2 and SDL2main for GDK ###
+
+Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL2 and SDL2main targets for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL2.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), `SDL2.lib`, and `SDL2main.lib` output files for your game project.
+
+*Alternatively*, you could setup your solution file to instead reference the SDL2/SDL2main project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL2 and SDL2main would both be built when your game is built.
+
+### 3. Configuring Project Settings ###
+
+While the Gaming.Desktop.x64 configuration sets most of the required settings, there are some additional items to configure for your game project under the Gaming.Desktop.x64 Configuration:
+
+*  Under C/C++ > General > Additional Include Directories, make sure the `SDL/include` path is referenced
+* Under Linker > General > Additional Library Directories, make sure to reference the path where the newly-built SDL2.lib and SDL2main.lib are
+* Under Linker > Input > Additional Dependencies, you need the following:
+  * `SDL2.lib`
+  * `SDL2main.lib` (unless not using)
+  * `xgameruntime.lib`
+  * `../Microsoft.Xbox.Services.141.GDK.C.Thunks.lib`
+* Note that in general, the GDK libraries depend on the MSVC C/C++ runtime, so there is no way to remove this dependency from a GDK program that links against GDK.
+
+### 4. Setting up SDL_main ###
+
+Rather than using your own implementation of `WinMain`, it's recommended that you instead `#include "SDL_main.h"` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
+
+### 5. Required DLLs ###
+
+The game will not launch in the debugger unless required DLLs are included in the directory that contains the game's .exe file. You need to make sure that the following files are copied into the directory:
+
+* Your SDL2.dll
+* "$(Console_GRDKExtLibRoot)Xbox.Services.API.C\DesignTime\CommonConfiguration\Neutral\Lib\Release\Microsoft.Xbox.Services.141.GDK.C.Thunks.dll"
+* XCurl.dll
+
+You can either copy these in a post-build step, or you can add the dlls into the project and set its Configuration Properties > General > Item type to "Copy file," which will also copy them into the output directory.
+
+### 6. Setting up MicrosoftGame.config ###
+
+You can copy `VisualC-GDK/tests/testgdk/MicrosoftGame.config` and use that as a starting point in your project. Minimally, you will want to change the Executable Name attribute, the DefaultDisplayName, and the Description.
+
+This file must be copied into the same directory as the game's .exe file. As with the DLLs, you can either use a post-build step or the "Copy file" item type.
+
+For basic testing, you do not need to change anything else in `MicrosoftGame.config`. However, if you want to test any Xbox Live services (such as logging in users) _or_ publish a package, you will need to setup a Game app on Partner Center.
+
+Then, you need to set the following values to the values from Partner Center:
+
+* Identity tag - Name and Publisher attributes
+* TitleId
+* MSAAppId
+
+### 7. Adding Required Logos
+
+Several logo PNG files are required to be able to launch the game, even from the debugger. You can use the sample logos provided in `VisualC-GDK/logos`. As with the other files, they must be copied into the same directory as the game's .exe file.
+
+
+### 8. Copying any Data Files ###
+
+When debugging GDK games, there is no way to specify a working directory. Therefore, any required game data must also be copied into the output directory, likely in a post-build step.
+
+
+### 9. Build and Run from Visual Studio ###
+
+At this point, you should be able to build and run your game from the Visual Studio Debugger. If you get any linker errors, make sure you double-check that you referenced all the required libs.
+
+If you are testing Xbox Live functionality, it's likely you will need to change to the Sandbox for your title. To do this:
+
+1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
+2. Switch the sandbox name with:
+   `XblPCSandbox SANDBOX.#`
+3. (To switch back to the retail sandbox):
+   `XblPCSandbox RETAIL`
+
+### 10. Packaging and Installing Locally
+
+You can use one of the test program's `PackageLayout.xml` as a starting point. Minimally, you will need to change the exe to the correct name and also reference any required game data. As with the other data files, it's easiest if you have this copy to the output directory, although it's not a requirement as you can specify relative paths to files.
+
+To create the package:
+
+1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
+2. `cd` to the directory containing the `PackageLayout.xml` with the correct paths (if you use the local path as in the sample package layout, this would be from your .exe output directory)
+3. `mkdir Package` to create an output directory
+4. To package the file into the `Package` directory, use:
+    `makepkg pack /f PackageLayout.xml /lt /d . /nogameos /pc /pd Package`
+5. To install the package, use:
+   `wdapp install PACKAGENAME.msixvc`
+6. Once the package is installed, you can run it from the start menu.
+7. As with when running from Visual Studio, if you need to test any Xbox Live functionality you must switch to the correct sandbox.
+
+
+Troubleshooting
+---------------
+
+#### Xbox Live Login does not work
+
+As of June 2022 GDK, you must have a valid Title Id and MSAAppId in order to test Xbox Live functionality such as user login. Make sure these are set correctly in the `MicrosoftGame.config`. This means that even testgdk will not let you login without setting these properties to valid values.
+
+Furthermore, confirm that your PC is set to the correct sandbox.
+
+
+#### "The current user has already installed an unpackaged version of this app. A packaged version cannot replace this." error when installing
+
+Prior to June 2022 GDK, running from the Visual Studio debugger would still locally register the app (and it would appear on the start menu). To fix this, you have to uninstall it (it's simplest to right click on it from the start menu to uninstall it).

libs/SDL2/docs/README-git.md

+git
+=========
+
+The latest development version of SDL is available via git.
+Git allows you to get up-to-the-minute fixes and enhancements;
+as a developer works on a source tree, you can use "git" to mirror that
+source tree instead of waiting for an official release. Please look
+at the Git website ( https://git-scm.com/ ) for more
+information on using git, where you can also download software for
+macOS, Windows, and Unix systems.
+
+    git clone https://github.com/libsdl-org/SDL
+
+If you are building SDL via configure, you will need to run autogen.sh
+before running configure.
+
+There is a web interface to the Git repository at:
+	http://github.com/libsdl-org/SDL/
+

libs/SDL2/docs/README-hg.md

-Mercurial
-=========
+We are no longer hosted in Mercurial. Please see README-git.md for details.
 
-The latest development version of SDL is available via Mercurial.
-Mercurial allows you to get up-to-the-minute fixes and enhancements;
-as a developer works on a source tree, you can use "hg" to mirror that
-source tree instead of waiting for an official release. Please look
-at the Mercurial website ( http://mercurial.selenic.com/ ) for more
-information on using hg, where you can also download software for
-Mac OS X, Windows, and Unix systems.
-
-    hg clone http://hg.libsdl.org/SDL
-
-If you are building SDL with an IDE, you will need to copy the file
-include/SDL_config.h.default to include/SDL_config.h before building.
-
-If you are building SDL via configure, you will need to run autogen.sh
-before running configure.
-
-There is a web interface to the subversion repository at:
-	http://hg.libsdl.org/SDL/
-
-There is an RSS feed available at that URL, for those that want to
-track commits in real time.
+Thanks!
 

libs/SDL2/docs/README-ios.md

 iOS
 ======
 
-==============================================================================
-Building the Simple DirectMedia Layer for iOS 5.1+
+Building the Simple DirectMedia Layer for iOS 9.0+
 ==============================================================================
 
-Requirements: Mac OS X 10.8 or later and the iOS 7+ SDK.
+Requirements: Mac OS X 10.9 or later and the iOS 9.0 or newer SDK.
 
 Instructions:
-1.  Open SDL.xcodeproj (located in Xcode-iOS/SDL) in Xcode.
-2.  Select your desired target, and hit build.
-
-There are three build targets:
-- libSDL.a:
-	Build SDL as a statically linked library
-- testsdl:
-	Build a test program (there are known test failures which are fine)
-- Template:
-	Package a project template together with the SDL for iPhone static libraries and copies of the SDL headers.  The template includes proper references to the SDL library and headers, skeleton code for a basic SDL program, and placeholder graphics for the application icon and startup screen.
-
-
-==============================================================================
-Build SDL for iOS from the command line
-==============================================================================
 
-1. cd (PATH WHERE THE SDL CODE IS)/build-scripts
-2. ./iosbuild.sh
-
-If everything goes fine, you should see a build/ios directory, inside there's
-two directories "lib" and "include". 
-"include" contains a copy of the SDL headers that you'll need for your project,
-make sure to configure XCode to look for headers there.
-"lib" contains find two files, libSDL2.a and libSDL2main.a, you have to add both 
-to your XCode project. These libraries contain three architectures in them,
-armv6 for legacy devices, armv7, and i386 (for the simulator).
-By default, iosbuild.sh will autodetect the SDK version you have installed using 
-xcodebuild -showsdks, and build for iOS >= 3.0, you can override this behaviour 
-by setting the MIN_OS_VERSION variable, ie:
+1. Open SDL.xcodeproj (located in Xcode/SDL) in Xcode.
+2. Select your desired target, and hit build.
 
-MIN_OS_VERSION=4.2 ./iosbuild.sh
 
-==============================================================================
 Using the Simple DirectMedia Layer for iOS
 ==============================================================================
 
-FIXME: This needs to be updated for the latest methods
+1. Run Xcode and create a new project using the iOS Game template, selecting the Objective C language and Metal game technology.
+2. In the main view, delete all files except for Assets and LaunchScreen
+3. Right click the project in the main view, select "Add Files...", and add the SDL project, Xcode/SDL/SDL.xcodeproj
+4. Select the project in the main view, go to the "Info" tab and under "Custom iOS Target Properties" remove the line "Main storyboard file base name"
+5. Select the project in the main view, go to the "Build Settings" tab, select "All", and edit "Header Search Path" and drag over the SDL "Public Headers" folder from the left
+6. Select the project in the main view, go to the "Build Phases" tab, select "Link Binary With Libraries", and add SDL2.framework from "Framework-iOS"
+7. Select the project in the main view, go to the "General" tab, scroll down to "Frameworks, Libraries, and Embedded Content", and select "Embed & Sign" for the SDL library.
+8. In the main view, expand SDL -> Library Source -> main -> uikit and drag SDL_uikit_main.c into your game files
+9. Add the source files that you would normally have for an SDL program, making sure to have #include "SDL.h" at the top of the file containing your main() function.
+10. Add any assets that your application needs.
+11. Enjoy!
 
-Here is the easiest method:
-1.  Build the SDL library (libSDL2.a) and the iPhone SDL Application template.
-2.  Install the iPhone SDL Application template by copying it to one of Xcode's template directories.  I recommend creating a directory called "SDL" in "/Developer/Platforms/iOS.platform/Developer/Library/Xcode/Project Templates/" and placing it there.
-3.  Start a new project using the template.  The project should be immediately ready for use with SDL.
 
-Here is a more manual method:
-1.  Create a new iOS view based application.
-2.  Build the SDL static library (libSDL2.a) for iOS and include them in your project.  Xcode will ignore the library that is not currently of the correct architecture, hence your app will work both on iOS and in the iOS Simulator.
-3.  Include the SDL header files in your project.
-4.  Remove the ApplicationDelegate.h and ApplicationDelegate.m files -- SDL for iOS provides its own UIApplicationDelegate.  Remove MainWindow.xib -- SDL for iOS produces its user interface programmatically.
-5.  Delete the contents of main.m and program your app as a regular SDL program instead.  You may replace main.m with your own main.c, but you must tell Xcode not to use the project prefix file, as it includes Objective-C code.
+TODO: Add information regarding App Store requirements such as icons, etc.
+
 
-==============================================================================
 Notes -- Retina / High-DPI and window sizes
 ==============================================================================
 
@@ -74,20 +46,20 @@ By default SDL will not use the full pixel density of the screen on
 Retina/high-dpi capable devices. Use the SDL_WINDOW_ALLOW_HIGHDPI flag when
 creating your window to enable high-dpi support.
 
-When high-dpi support is enabled, SDL_GetWindowSize and display mode sizes
+When high-dpi support is enabled, SDL_GetWindowSize() and display mode sizes
 will still be in "screen coordinates" rather than pixels, but the window will
 have a much greater pixel density when the device supports it, and the
-SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize functions (depending on
+SDL_GL_GetDrawableSize() or SDL_GetRendererOutputSize() functions (depending on
 whether raw OpenGL or the SDL_Render API is used) can be queried to determine
 the size in pixels of the drawable screen framebuffer.
 
 Some OpenGL ES functions such as glViewport expect sizes in pixels rather than
 sizes in screen coordinates. When doing 2D rendering with OpenGL ES, an
 orthographic projection matrix using the size in screen coordinates
-(SDL_GetWindowSize) can be used in order to display content at the same scale
+(SDL_GetWindowSize()) can be used in order to display content at the same scale
 no matter whether a Retina device is used or not.
 
-==============================================================================
+
 Notes -- Application events
 ==============================================================================
 
@@ -150,21 +122,20 @@ e.g.
     }
 
 
-==============================================================================
 Notes -- Accelerometer as Joystick
 ==============================================================================
 
 SDL for iPhone supports polling the built in accelerometer as a joystick device.  For an example on how to do this, see the accelerometer.c in the demos directory.
 
-The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis reports joystick values as signed integers.  Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver.  To convert SDL_JoystickGetAxis reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
+The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis() reports joystick values as signed integers.  Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver.  To convert SDL_JoystickGetAxis() reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
+
 
-==============================================================================
 Notes -- OpenGL ES
 ==============================================================================
 
 Your SDL application for iOS uses OpenGL ES for video by default.
 
-OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute.
+OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute().
 
 If your application doesn't use OpenGL's depth buffer, you may find significant performance improvement by setting SDL_GL_DEPTH_SIZE to 0.
 
@@ -172,13 +143,13 @@ Finally, if your application completely redraws the screen each frame, you may f
 
 OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided in other operating systems. Special care must be taken because of this:
 
-- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow is called.
-- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow is called.
+- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow() is called.
+- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow() is called.
 - If multisample antialiasing (MSAA) is used and glReadPixels is used on the screen, the drawable framebuffer must be resolved to the MSAA resolve framebuffer (via glBlitFramebuffer or glResolveMultisampleFramebufferAPPLE), and the MSAA resolve framebuffer must be bound to the GL_READ_FRAMEBUFFER binding point, before glReadPixels is called.
 
-The above objects can be obtained via SDL_GetWindowWMInfo (in SDL_syswm.h).
+The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
+
 
-==============================================================================
 Notes -- Keyboard
 ==============================================================================
 
@@ -194,7 +165,12 @@ SDL_bool SDL_IsTextInputActive()
 	-- returns whether or not text events are enabled (and the onscreen keyboard is visible)
 
 
+Notes -- Mouse
 ==============================================================================
+
+iOS now supports Bluetooth mice on iPad, but by default will provide the mouse input as touch. In order for SDL to see the real mouse events, you should set the key UIApplicationSupportsIndirectInputEvents to true in your Info.plist
+
+
 Notes -- Reading and Writing files
 ==============================================================================
 
@@ -214,12 +190,44 @@ When your SDL based iPhone application starts up, it sets the working directory
 More information on this subject is available here:
 http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html
 
+
+Notes -- xcFramework
 ==============================================================================
+
+The SDL.xcodeproj file now includes a target to build SDL2.xcframework. An xcframework is a new (Xcode 11) uber-framework which can handle any combination of processor type and target OS platform.
+
+In the past, iOS devices were always an ARM variant processor, and the simulator was always i386 or x86_64, and thus libraries could be combined into a single framework for both simulator and device. With the introduction of the Apple Silicon ARM-based machines, regular frameworks would collide as CPU type was no longer sufficient to differentiate the platform. So Apple created the new xcframework library package.
+
+The xcframework target builds into a Products directory alongside the SDL.xcodeproj file, as SDL2.xcframework. This can be brought in to any iOS project and will function properly for both simulator and device, no matter their CPUs. Note that Intel Macs cannot cross-compile for Apple Silicon Macs. If you need AS compatibility, perform this build on an Apple Silicon Mac.
+
+This target requires Xcode 11 or later. The target will simply fail to build if attempted on older Xcodes.
+
+In addition, on Apple platforms, main() cannot be in a dynamically loaded library. This means that iOS apps which used the statically-linked libSDL2.lib and now link with the xcframwork will need to define their own main() to call SDL_UIKitRunApp(), like this:
+
+#ifndef SDL_MAIN_HANDLED
+#ifdef main
+#undef main
+#endif
+
+int
+main(int argc, char *argv[])
+{
+	return SDL_UIKitRunApp(argc, argv, SDL_main);
+}
+#endif /* !SDL_MAIN_HANDLED */
+
+Using an xcFramework is similar to using a regular framework. However, issues have been seen with the build system not seeing the headers in the xcFramework. To remedy this, add the path to the xcFramework in your app's target ==> Build Settings ==> Framework Search Paths and mark it recursive (this is critical). Also critical is to remove "*.framework" from Build Settings ==> Sub-Directories to Exclude in Recursive Searches. Clean the build folder, and on your next build the build system should be able to see any of these in your code, as expected:
+
+#include "SDL_main.h"
+#include <SDL.h>
+#include <SDL_main.h>
+
+
 Notes -- iPhone SDL limitations
 ==============================================================================
 
 Windows:
-	Full-size, single window applications only.  You cannot create multi-window SDL applications for iPhone OS.  The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow the flag SDL_WINDOW_BORDERLESS).
+	Full-size, single window applications only.  You cannot create multi-window SDL applications for iPhone OS.  The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow() the flag SDL_WINDOW_BORDERLESS).
 
 Textures:
 	The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_BGR888, and SDL_PIXELFORMAT_RGB24 pixel formats.
@@ -227,7 +235,23 @@ Textures:
 Loading Shared Objects:
 	This is disabled by default since it seems to break the terms of the iOS SDK agreement for iOS versions prior to iOS 8. It can be re-enabled in SDL_config_iphoneos.h.
 
+
+Notes -- CoreBluetooth.framework
 ==============================================================================
+
+SDL_JOYSTICK_HIDAPI is disabled by default. It can give you access to a lot
+more game controller devices, but it requires permission from the user before
+your app will be able to talk to the Bluetooth hardware. "Made For iOS"
+branded controllers do not need this as we don't have to speak to them
+directly with raw bluetooth, so many apps can live without this.
+
+You'll need to link with CoreBluetooth.framework and add something like this
+to your Info.plist:
+
+<key>NSBluetoothPeripheralUsageDescription</key>
+<string>MyApp would like to remain connected to nearby bluetooth Game Controllers and Game Pads even when you're not using the app.</string>
+
+
 Game Center
 ==============================================================================
 
@@ -264,3 +288,20 @@ e.g.
     #endif
         return 0;
     }
+
+
+Deploying to older versions of iOS
+==============================================================================
+
+SDL supports deploying to older versions of iOS than are supported by the latest version of Xcode, all the way back to iOS 8.0
+
+In order to do that you need to download an older version of Xcode:
+https://developer.apple.com/download/more/?name=Xcode
+
+Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
+
+Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
+
+Open your project and set your deployment target to the desired version of iOS
+
+Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController

libs/SDL2/docs/README-kmsbsd.md

+KMSDRM on *BSD
+==================================================
+
+KMSDRM is supported on FreeBSD and OpenBSD. DragonFlyBSD works but requires being a root user. NetBSD isn't supported yet because the application will crash when creating the KMSDRM screen.
+
+WSCONS support has been brought back, but only as an input backend. It will not be brought back as a video backend to ease maintenance.
+
+OpenBSD note: Note that the video backend assumes that the user has read/write permissions to the /dev/drm* devices.
+
+
+SDL2 WSCONS input backend features
+===================================================
+1. It is keymap-aware; it will work properly with different keymaps.
+2. It has mouse support.
+3. Accent input is supported.
+4. Compose keys are supported.
+5. AltGr and Meta Shift keys work as intended.
+
+Partially working or no input on OpenBSD/NetBSD.
+==================================================
+
+The WSCONS input backend needs read/write access to the /dev/wskbd* devices, without which it will not work properly. /dev/wsmouse must also be read/write accessible, otherwise mouse input will not work.
+
+Partially working or no input on FreeBSD.
+==================================================
+
+The evdev devices are only accessible to the root user by default. Edit devfs rules to allow access to such devices. The /dev/kbd* devices are also only accessible to the root user by default. Edit devfs rules to allow access to such devices.

libs/SDL2/docs/README-linux.md

@@ -3,38 +3,52 @@ Linux
 
 By default SDL will only link against glibc, the rest of the features will be
 enabled dynamically at runtime depending on the available features on the target
-system. So, for example if you built SDL with Xinerama support and the target
-system does not have the Xinerama libraries installed, it will be disabled
+system. So, for example if you built SDL with XRandR support and the target
+system does not have the XRandR libraries installed, it will be disabled
 at runtime, and you won't get a missing library error, at least with the
 default configuration parameters.
 
 
-================================================================================
 Build Dependencies
-================================================================================
+--------------------------------------------------------------------------------
+
+Ubuntu 18.04, all available features enabled:
 
-Ubuntu 13.04, all available features enabled:
+    sudo apt-get install build-essential git make autoconf automake libtool \
+    pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev \
+    libaudio-dev libjack-dev libsndio-dev libsamplerate0-dev libx11-dev libxext-dev \
+    libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libwayland-dev \
+    libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev \
+    libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev fcitx-libs-dev
 
-sudo apt-get install build-essential mercurial make cmake autoconf automake \
-libtool libasound2-dev libpulse-dev libaudio-dev libx11-dev libxext-dev \
-libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev \
-libxss-dev libgl1-mesa-dev libesd0-dev libdbus-1-dev libudev-dev \
-libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev
+Ubuntu 22.04+ can also add `libpipewire-0.3-dev libdecor-0-dev` to that command line.
 
-Ubuntu 14.04 can also add "libwayland-dev libmirclient-dev libxkbcommon-dev"
-to that command line for Wayland and Mir support.
+Fedora 35, all available features enabled:
+
+    sudo yum install gcc git-core make cmake autoconf automake libtool \
+    alsa-lib-devel pulseaudio-libs-devel nas-devel pipewire-devel \
+    libX11-devel libXext-devel libXrandr-devel libXcursor-devel libXfixes-devel \
+    libXi-devel libXScrnSaver-devel dbus-devel ibus-devel fcitx-devel \
+    systemd-devel mesa-libGL-devel libxkbcommon-devel mesa-libGLES-devel \
+    mesa-libEGL-devel vulkan-devel wayland-devel wayland-protocols-devel \
+    libdrm-devel mesa-libgbm-devel libusb-devel libdecor-devel \
+    libsamplerate-devel pipewire-jack-audio-connection-kit-devel \
 
 NOTES:
-- This includes all the audio targets except arts, because Ubuntu pulled the 
-  artsc0-dev package, but in theory SDL still supports it.
+- This includes all the audio targets except arts and esd, because Ubuntu
+  (and/or Debian) pulled their packages, but in theory SDL still supports them.
+  The sndio audio target is also unavailable on Fedora.
+- libsamplerate0-dev lets SDL optionally link to libresamplerate at runtime
+  for higher-quality audio resampling. SDL will work without it if the library
+  is missing, so it's safe to build in support even if the end user doesn't
+  have this library installed.
 - DirectFB isn't included because the configure script (currently) fails to find
   it at all. You can do "sudo apt-get install libdirectfb-dev" and fix the
   configure script to include DirectFB support. Send patches.  :)
 
 
-================================================================================
 Joystick does not work
-================================================================================
+--------------------------------------------------------------------------------
 
 If you compiled or are using a version of SDL with udev support (and you should!)
 there's a few issues that may cause SDL to fail to detect your joystick. To

libs/SDL2/docs/README-macosx.md → libs/SDL2/docs/README-macos.md

-Mac OS X
-==============================================================================
+# Mac OS X (aka macOS).
 
 These instructions are for people using Apple's Mac OS X (pronounced
-"ten").
+"ten"), which in newer versions is just referred to as "macOS".
 
-From the developer's point of view, OS X is a sort of hybrid Mac and
+From the developer's point of view, macOS is a sort of hybrid Mac and
 Unix system, and you have the option of using either traditional
 command line tools or Apple's IDE Xcode.
 
+# Command Line Build
+
 To build SDL using the command line, use the standard configure and make
 process:
 
-	./configure
+```bash
+mkdir build
+cd build
+../configure
 make
 sudo make install
+```
+
+CMake is also known to work, although it continues to be a work in progress:
+
+```bash
+mkdir build
+cd build
+cmake -DCMAKE_BUILD_TYPE=Release ..
+make
+sudo make install
+```
+
 
 You can also build SDL as a Universal library (a single binary for both
-32-bit and 64-bit Intel architectures), on Mac OS X 10.7 and newer, by using
-the gcc-fat.sh script in build-scripts:
+64-bit Intel and ARM architectures), by using the build-scripts/clang-fat.sh
+script.
 
-    mkdir mybuild
-    cd mybuild
-    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++fat.sh ../configure
+```bash
+mkdir build
+cd build
+CC=$PWD/../build-scripts/clang-fat.sh ../configure
 make
 sudo make install
+```
 
-This script builds SDL with 10.5 ABI compatibility on i386 and 10.6
-ABI compatibility on x86_64 architectures.  For best compatibility you
+This script builds SDL with 10.9 ABI compatibility on 64-bit Intel and 11.0
+ABI compatibility on ARM64 architectures.  For best compatibility you
 should compile your application the same way.
 
-Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK
-(even if you target back to 10.5 systems). PowerPC support for Mac OS X has
-been officially dropped as of SDL 2.0.2.
+Please note that building SDL requires at least Xcode 6 and the 10.9 SDK.
+PowerPC support for macOS has been officially dropped as of SDL 2.0.2.
+32-bit Intel and macOS 10.8 runtime support has been officially dropped as
+of SDL 2.24.0.
 
 To use the library once it's built, you essential have two possibilities:
 use the traditional autoconf/automake/make method, or use Xcode.
 
-==============================================================================
-Caveats for using SDL with Mac OS X
-==============================================================================
 
-Some things you have to be aware of when using SDL on Mac OS X:
+# Caveats for using SDL with Mac OS X
 
-- If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
+If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
 SDL will not register its own. This means that SDL will not terminate using
 SDL_Quit if it receives a termination request, it will terminate like a
 normal app, and it will not send a SDL_DROPFILE when you request to open a
@@ -50,6 +66,7 @@ Some things you have to be aware of when using SDL on Mac OS X:
 NSApplicationDelegate implementation:
 
 
+```objc
 - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
 {
     if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
@@ -72,32 +89,33 @@ Some things you have to be aware of when using SDL on Mac OS X:
 
     return NO;
 }
+```
 
-==============================================================================
-Using the Simple DirectMedia Layer with a traditional Makefile
-==============================================================================
+# Using the Simple DirectMedia Layer with a traditional Makefile
 
 An existing autoconf/automake build system for your SDL app has good chances
-to work almost unchanged on OS X. However, to produce a "real" Mac OS X binary
+to work almost unchanged on macOS. However, to produce a "real" Mac binary
 that you can distribute to users, you need to put the generated binary into a
-so called "bundle", which basically is a fancy folder with a name like
+so called "bundle", which is basically a fancy folder with a name like
 "MyCoolGame.app".
 
 To get this build automatically, add something like the following rule to
 your Makefile.am:
 
+```make
 bundle_contents = APP_NAME.app/Contents
 APP_NAME_bundle: EXE_NAME
 	mkdir -p $(bundle_contents)/MacOS
 	mkdir -p $(bundle_contents)/Resources
 	echo "APPL????" > $(bundle_contents)/PkgInfo
 	$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/
+```
 
-You should replace EXE_NAME with the name of the executable. APP_NAME is what
-will be visible to the user in the Finder. Usually it will be the same
-as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME 
-usually is "TestGame". You might also want to use @PACKAGE@ to use the package
-name as specified in your configure.in file.
+You should replace `EXE_NAME` with the name of the executable. `APP_NAME` is
+what will be visible to the user in the Finder. Usually it will be the same
+as `EXE_NAME` but capitalized. E.g. if `EXE_NAME` is "testgame" then `APP_NAME`
+usually is "TestGame". You might also want to use `@PACKAGE@` to use the
+package name as specified in your configure.ac file.
 
 If your project builds more than one application, you will have to do a bit
 more. For each of your target applications, you need a separate rule.
@@ -105,33 +123,43 @@ more. For each of your target applications, you need a separate rule.
 If you want the created bundles to be installed, you may want to add this
 rule to your Makefile.am:
 
+```make
 install-exec-hook: APP_NAME_bundle
 	rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
 	mkdir -p $(DESTDIR)$(prefix)/Applications/
 	cp -r $< /$(DESTDIR)$(prefix)Applications/
+```
 
 This rule takes the Bundle created by the rule from step 3 and installs them
-into $(DESTDIR)$(prefix)/Applications/.
+into "$(DESTDIR)$(prefix)/Applications/".
 
 Again, if you want to install multiple applications, you will have to augment
 the make rule accordingly.
 
-
 But beware! That is only part of the story! With the above, you end up with
-a bare bone .app bundle, which is double clickable from the Finder. But
+a barebones .app bundle, which is double-clickable from the Finder. But
 there are some more things you should do before shipping your product...
 
-1) The bundle right now probably is dynamically linked against SDL. That 
+1. The bundle right now probably is dynamically linked against SDL. That
    means that when you copy it to another computer, *it will not run*,
    unless you also install SDL on that other computer. A good solution
    for this dilemma is to static link against SDL. On OS X, you can
    achieve that by linking against the libraries listed by
+
+   ```bash
    sdl-config --static-libs
+   ```
+
    instead of those listed by
+
+   ```bash
    sdl-config --libs
+   ```
+
    Depending on how exactly SDL is integrated into your build systems, the
    way to achieve that varies, so I won't describe it here in detail
-2) Add an 'Info.plist' to your application. That is a special XML file which
+
+2. Add an 'Info.plist' to your application. That is a special XML file which
    contains some meta-information about your application (like some copyright
    information, the version of your app, the name of an optional icon file,
    and other things). Part of that information is displayed by the Finder
@@ -140,28 +168,31 @@ there are some more things you should do before shipping your product...
 
 
 As a final remark, let me add that I use some of the techniques (and some
-variations of them) in Exult and ScummVM; both are available in source on
+variations of them) in [Exult](https://github.com/exult/exult) and
+[ScummVM](https://github.com/scummvm/scummvm); both are available in source on
 the net, so feel free to take a peek at them for inspiration!
 
 
-==============================================================================
-Using the Simple DirectMedia Layer with Xcode
-==============================================================================
+# Using the Simple DirectMedia Layer with Xcode
 
 These instructions are for using Apple's Xcode IDE to build SDL applications.
 
-- First steps
+## First steps
 
 The first thing to do is to unpack the Xcode.tar.gz archive in the
 top level SDL directory (where the Xcode.tar.gz archive resides).
 Because Stuffit Expander will unpack the archive into a subdirectory,
 you should unpack the archive manually from the command line:
+
+```bash
 cd [path_to_SDL_source]
 tar zxf Xcode.tar.gz
+```
+
 This will create a new folder called Xcode, which you can browse
 normally from the Finder.
 
-- Building the Framework
+## Building the Framework
 
 The SDL Library is packaged as a framework bundle, an organized
 relocatable folder hierarchy of executable code, interface headers,
@@ -175,50 +206,71 @@ By default, the framework bundle "SDL.framework" is installed in
 it to be located there. However, it will function the same in any of the
 following locations:
 
-    ~/Library/Frameworks
-    /Local/Library/Frameworks
-    /System/Library/Frameworks
+* ~/Library/Frameworks
+* /Local/Library/Frameworks
+* /System/Library/Frameworks
+
+## Build Options
 
-- Build Options
 There are two "Build Styles" (See the "Targets" tab) for SDL.
 "Deployment" should be used if you aren't tweaking the SDL library.
 "Development" should be used to debug SDL apps or the library itself.
 
-- Building the Testers
+## Building the Testers
+
 Open the SDLTest project and build away!
 
-- Using the Project Stationary
+## Using the Project Stationary
+
 Copy the stationary to the indicated folders to access it from
 the "New Project" and "Add target" menus. What could be easier?
 
-- Setting up a new project by hand
+## Setting up a new project by hand
+
 Some of you won't want to use the Stationary so I'll give some tips:
-    * Create a new "Cocoa Application"
-    * Add src/main/macosx/SDLMain.m , .h and .nib to your project
-    * Remove "main.c" from your project
-    * Remove "MainMenu.nib" from your project
-    * Add "$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
-    * Add "$(HOME)/Library/Frameworks" to the frameworks search path
+
+(this is accurate as of Xcode 12.5.)
+
+* Click "File" -> "New" -> "Project...
+* Choose "macOS" and then "App" from the "Application" section.
+* Fill out the options in the next window. User interface is "XIB" and
+  Language is "Objective-C".
+* Remove "main.m" from your project
+* Remove "MainMenu.xib" from your project
+* Remove "AppDelegates.*" from your project
+* Add "\$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
+* Add "\$(HOME)/Library/Frameworks" to the frameworks search path
 * Add "-framework SDL -framework Foundation -framework AppKit" to "OTHER_LDFLAGS"
-    * Set the "Main Nib File" under "Application Settings" to "SDLMain.nib"
 * Add your files
 * Clean and build
 
-- Building from command line
-    Use pbxbuild in the same directory as your .pbproj file
+## Building from command line
+
+Use `xcode-build` in the same directory as your .pbxproj file
+
+## Running your app
 
-- Running your app
 You can send command line args to your app by either invoking it from
 the command line (in *.app/Contents/MacOS) or by entering them in the
-    "Executables" panel of the target settings.
+Executables" panel of the target settings.
+
+# Implementation Notes
 
-- Implementation Notes
 Some things that may be of interest about how it all works...
-    * Working directory
-        As defined in the SDL_main.m file, the working directory of your SDL app
-        is by default set to its parent. You may wish to change this to better
-        suit your needs.
-    * You have a Cocoa App!
+
+## Working directory
+
+In SDL 1.2, the working directory of your SDL app is by default set to its
+parent, but this is no longer the case in SDL 2.0. SDL2 does change the
+working directory, which means it'll be whatever the command line prompt
+that launched the program was using, or if launched by double-clicking in
+the finger, it will be "/", the _root of the filesystem_. Plan accordingly!
+You can use SDL_GetBasePath() to find where the program is running from and
+chdir() there directly.
+
+
+## You have a Cocoa App!
+
 Your SDL app is essentially a Cocoa application. When your app
 starts up and the libraries finish loading, a Cocoa procedure is called,
 which sets up the working directory and calls your main() method.
@@ -226,5 +278,8 @@ following locations:
 to SDL. You cannot, however, easily change the SDL window itself.
 Functionality may be added in the future to help this.
 
+# Bug reports
+
+Bugs are tracked at [the GitHub issue tracker](https://github.com/libsdl-org/SDL/issues/).
+Please feel free to report bugs there!
 
-Known bugs are listed in the file "BUGS"

libs/SDL2/docs/README-n3ds.md

+# Nintendo 3DS
+
+SDL port for the Nintendo 3DS [Homebrew toolchain](https://devkitpro.org/) contributed by:
+
+-   [Pierre Wendling](https://github.com/FtZPetruska)
+
+Credits to:
+
+-   The awesome people who ported SDL to other homebrew platforms.
+-   The Devkitpro team for making all the tools necessary to achieve this.
+
+## Building
+
+To build for the Nintendo 3DS, make sure you have devkitARM and cmake installed and run:
+
+```bash
+cmake -S. -Bbuild -DCMAKE_TOOLCHAIN_FILE="$DEVKITPRO/cmake/3DS.cmake" -DCMAKE_BUILD_TYPE=Release
+cmake --build build
+cmake --install build
+```
+
+## Notes
+
+-   Currently only software rendering is supported.
+-   SDL2main should be used to ensure ROMFS is enabled.
+-   By default, the extra L2 cache and higher clock speeds of the New 2/3DS lineup are enabled. If you wish to turn it off, use `osSetSpeedupEnable(false)` in your main function.
+-   `SDL_GetBasePath` returns the romfs root instead of the executable's directory.
+-   The Nintendo 3DS uses a cooperative threading model on a single core, meaning a thread will never yield unless done manually through the `SDL_Delay` functions, or blocking waits (`SDL_LockMutex`, `SDL_SemWait`, `SDL_CondWait`, `SDL_WaitThread`). To avoid starving other threads, `SDL_SemTryWait` and `SDL_SemWaitTimeout` will yield if they fail to acquire the semaphore, see https://github.com/libsdl-org/SDL/pull/6776 for more information.

libs/SDL2/docs/README-ngage.md

+Nokia N-Gage
+============
+
+SDL2 port for Symbian S60v1 and v2 with a main focus on the Nokia N-Gage
+(Classic and QD) by [Michael Fitzmayer](https://github.com/mupfdev).
+
+Compiling
+---------
+
+SDL is part of the [N-Gage SDK.](https://github.com/ngagesdk) project.
+The library is included in the
+[toolchain](https://github.com/ngagesdk/ngage-toolchain) as a
+sub-module.
+
+A complete example project based on SDL2 can be found in the GitHub
+account of the SDK: [Wordle](https://github.com/ngagesdk/wordle).
+
+Current level of implementation
+-------------------------------
+
+The video driver currently provides full screen video support with
+keyboard input.
+
+At the moment only the software renderer works.
+
+Audio is not yet implemented.
+
+Acknowledgements
+----------------
+
+Thanks to Hannu Viitala, Kimmo Kinnunen and Markus Mertama for the
+valuable insight into Symbian programming.  Without the SDL 1.2 port
+which was specially developed for CDoom (Doom for the Nokia 9210), this
+adaptation would not have been possible.
+
+I would like to thank my friends
+[Razvan](https://twitter.com/bewarerazvan) and [Dan
+Whelan](https://danwhelan.ie/), for their continuous support.  Without
+you and the [N-Gage community](https://discord.gg/dbUzqJ26vs), I would
+have lost my patience long ago.
+
+Last but not least, I would like to thank the development team of
+[EKA2L1](https://12z1.com/) (an experimental Symbian OS emulator). Your
+patience and support in troubleshooting helped me a lot.

libs/SDL2/docs/README-os2.md

+Simple DirectMedia Layer 2 for OS/2 & eComStation
+================================================================================
+SDL port for OS/2, authored by Andrey Vasilkin <digi@os2.snc.ru>, 2016
+
+
+OpenGL not supported by this port.
+
+Additional optional environment variables:
+
+SDL_AUDIO_SHARE
+  Values: 0 or 1, default is 0
+  Initializes the device as shareable or exclusively acquired.
+
+SDL_VIDEODRIVER
+  Values: DIVE or VMAN, default is DIVE
+  Use video subsystem: Direct interface video extensions (DIVE) or
+  Video Manager (VMAN).
+
+You may significantly increase video output speed with OS4 kernel and patched
+files vman.dll and dive.dll or with latest versions of ACPI support and video
+driver Panorama.
+
+Latest versions of OS/4 kernel:
+  http://gus.biysk.ru/os4/
+ (Info: https://www.os2world.com/wiki/index.php/Phoenix_OS/4)
+
+Patched files vman.dll and dive.dll:
+  http://gus.biysk.ru/os4/test/pached_dll/PATCHED_DLL.RAR
+
+
+Compiling:
+----------
+
+Open Watcom 1.9 or newer is tested. For the new Open Watcom V2 fork, see:
+https://github.com/open-watcom/ and https://open-watcom.github.io
+WATCOM environment variable must to be set to the Open Watcom install
+directory. To compile, run: wmake -f Makefile.os2
+
+
+Installing:
+-----------
+
+- eComStation:
+
+  If you have previously installed SDL2, make a Backup copy of SDL2.dll
+  located in D:\ecs\dll (where D: is disk on which installed eComStation).
+  Stop all programs running with SDL2. Copy SDL2.dll to D:\ecs\dll
+
+- OS/2:
+
+  Copy SDL2.dll to any directory on your LIBPATH.  If you have a previous
+  version installed, close all SDL2 applications before replacing the old
+  copy.  Also make sure that any other older versions of DLLs are removed
+  from your system.
+
+
+Joysticks in SDL2:
+------------------
+
+The joystick code in SDL2 is a direct forward-port from the SDL-1.2 version.
+Here is the original documentation from SDL-1.2:
+
+The Joystick detection only works for standard joysticks (2 buttons, 2 axes
+and the like). Therefore, if you use a non-standard joystick, you should
+specify its features in the SDL_OS2_JOYSTICK environment variable in a batch
+file or CONFIG.SYS, so SDL applications can provide full capability to your
+device. The syntax is:
+
+SET SDL_OS2_JOYSTICK=[JOYSTICK_NAME] [AXES] [BUTTONS] [HATS] [BALLS]
+
+So, it you have a Gravis GamePad with 4 axes, 2 buttons, 2 hats and 0 balls,
+the line should be:
+
+SET SDL_OS2_JOYSTICK=Gravis_GamePad 4 2 2 0
+
+If you want to add spaces in your joystick name, just surround it with
+quotes or double-quotes:
+
+SET SDL_OS2_JOYSTICK='Gravis GamePad' 4 2 2 0
+
+or
+
+SET SDL_OS2_JOYSTICK="Gravis GamePad" 4 2 2 0
+
+   Note however that Balls and Hats are not supported under OS/2, and the
+value will be ignored... but it is wise to define these correctly because
+in the future those can be supported.
+
+   Also the number of buttons is limited to 2 when using two joysticks,
+4 when using one joystick with 4 axes, 6 when using a joystick with 3 axes
+and 8 when using a joystick with 2 axes. Notice however these are limitations
+of the Joystick Port hardware, not OS/2.

libs/SDL2/docs/README-porting.md

@@ -5,7 +5,7 @@ Porting
 
   The first thing you have to do when porting to a new platform, is look at
 include/SDL_platform.h and create an entry there for your operating system.
-The standard format is __PLATFORM__, where PLATFORM is the name of the OS.
+The standard format is "__PLATFORM__", where PLATFORM is the name of the OS.
 Ideally SDL_platform.h will be able to auto-detect the system it's building
 on based on C preprocessor symbols.
 
@@ -13,9 +13,11 @@ There are two basic ways of building SDL at the moment:
 
 1. The "UNIX" way:  ./configure; make; make install
 
-   If you have a GNUish system, then you might try this.  Edit configure.in,
+   If you have a GNUish system, then you might try this.  Edit configure.ac,
    take a look at the large section labelled:
+
 	"Set up the configuration based on the host platform!"
+
    Add a section for your platform, and then re-run autogen.sh and build!
 
 2. Using an IDE:
@@ -23,10 +25,11 @@ There are two basic ways of building SDL at the moment:
    If you're using an IDE or other non-configure build system, you'll probably
    want to create a custom SDL_config.h for your platform.  Edit SDL_config.h,
    add a section for your platform, and create a custom SDL_config_{platform}.h,
-   based on SDL_config.h.minimal and SDL_config.h.in
+   based on SDL_config_minimal.h and SDL_config.h.in
 
    Add the top level include directory to the header search path, and then add
    the following sources to the project:
+
 	src/*.c
 	src/atomic/*.c
 	src/audio/*.c
@@ -37,6 +40,7 @@ There are two basic ways of building SDL at the moment:
 	src/joystick/*.c
 	src/power/*.c
 	src/render/*.c
+	src/render/software/*.c
 	src/stdlib/*.c
 	src/thread/*.c
 	src/timer/*.c

libs/SDL2/docs/README-ps2.md

+PS2
+======
+SDL2 port for the Sony Playstation 2 contributed by:
+- Francisco Javier Trujillo Mata
+
+
+Credit to
+   - The guys that ported SDL to PSP & Vita because I'm taking them as reference.
+   - David G. F. for helping me with several issues and tests.
+
+## Building
+To build SDL2 library for the PS2, make sure you have the latest PS2Dev status and run:
+```bash
+cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PS2DEV/ps2sdk/ps2dev.cmake
+cmake --build build
+cmake --install build
+```
+
+## Hints
+The PS2 port has a special Hint for having a dynamic VSYNC. The Hint is `SDL_HINT_PS2_DYNAMIC_VSYNC`.
+If you enabled the dynamic vsync having as well `SDL_RENDERER_PRESENTVSYNC` enabled, then if the app is not able to run at 60 FPS, automatically the `vsync` will be disabled having a better performance, instead of droping FPS to 30.
+
+## Notes
+If you trying to debug a SDL app through [ps2client](https://github.com/ps2dev/ps2client) you need to avoid the IOP reset, otherwise you will lose the conection with your computer.
+So to avoid the reset of the IOP CPU, you need to call to the macro `SDL_PS2_SKIP_IOP_RESET();`.
+It could be something similar as:
+```c
+.....
+
+SDL_PS2_SKIP_IOP_RESET();
+
+int main(int argc, char *argv[])
+{
+.....
+```
+For a release binary is recommendable to reset the IOP always.
+
+Remember to do a clean compilation everytime you enable or disable the `SDL_PS2_SKIP_IOP_RESET` otherwise the change won't be reflected.
+
+## Getting PS2 Dev
+[Installing PS2 Dev](https://github.com/ps2dev/ps2dev)
+
+## Running on PCSX2 Emulator
+[PCSX2](https://github.com/PCSX2/pcsx2)
+
+[More PCSX2 information](https://pcsx2.net/)
+
+## To Do
+- PS2 Screen Keyboard
+- Dialogs
+- Others

libs/SDL2/docs/README-psp.md

 PSP
 ======
-SDL port for the Sony PSP contributed by 
-   Captian Lex 
+SDL2 port for the Sony PSP contributed by:
+- Captian Lex
+- Francisco Javier Trujillo Mata
+- Wouter Wijsman
+
 
 Credit to
    Marcus R.Brown,Jim Paris,Matthew H for the original SDL 1.2 for PSP
    Geecko for his PSP GU lib "Glib2d"
 
-Building
---------
-To build for the PSP, make sure psp-config is in the path and run:
-   make -f Makefile.psp
+## Building
+To build SDL2 library for the PSP, make sure you have the latest PSPDev status and run:
+```bash
+cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PSPDEV/psp/share/pspdev.cmake
+cmake --build build
+cmake --install build
+```
+
+
+## Getting PSP Dev
+[Installing PSP Dev](https://github.com/pspdev/pspdev)
+
+## Running on PPSSPP Emulator
+[PPSSPP](https://github.com/hrydgard/ppsspp)
+
+[Build Instructions](https://github.com/hrydgard/ppsspp/wiki/Build-instructions)
 
 
+## Compiling a HelloWorld
+[PSP Hello World](https://psp-dev.org/doku.php?id=tutorial:hello_world)
 
-To Do
-------
-PSP Screen Keyboard
+## To Do
+- PSP Screen Keyboard
+- Dialogs

libs/SDL2/docs/README-raspberrypi.md

 Raspberry Pi
-================================================================================
+============
 
 Requirements:
 
 Raspbian (other Linux distros may work as well).
 
-================================================================================
 Features
-================================================================================
+--------
 
 * Works without X11
 * Hardware accelerated OpenGL ES 2.x
@@ -16,20 +15,28 @@ Raspbian (other Linux distros may work as well).
 * Hotplugging of input devices via UDEV
 
 
-================================================================================
 Raspbian Build Dependencies
-================================================================================
+---------------------------
 
 sudo apt-get install libudev-dev libasound2-dev libdbus-1-dev
 
 You also need the VideoCore binary stuff that ships in /opt/vc for EGL and
-OpenGL ES 2.x, it usually comes pre installed, but in any case:
+OpenGL ES 2.x, it usually comes pre-installed, but in any case:
 
 sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
 
-================================================================================
+
+NEON
+----
+
+If your Pi has NEON support, make sure you add -mfpu=neon to your CFLAGS so
+that SDL will select some otherwise-disabled highly-optimized code. The
+original Pi units don't have NEON, the Pi2 probably does, and the Pi3
+definitely does.
+
+
 Cross compiling from x86 Linux
-================================================================================
+------------------------------
 
 To cross compile SDL for Raspbian from your desktop machine, you'll need a
 Raspbian system root and the cross compilation tools. We'll assume these tools
@@ -37,9 +44,9 @@ will be placed in /opt/rpi-tools
 
     sudo git clone --depth 1 https://github.com/raspberrypi/tools /opt/rpi-tools
 
-You'll also need a Rasbian binary image.
+You'll also need a Raspbian binary image.
 Get it from: http://downloads.raspberrypi.org/raspbian_latest
-After unzipping, you'll get file with a name like: <date>-wheezy-raspbian.img
+After unzipping, you'll get file with a name like: "<date>-wheezy-raspbian.img"
 Let's assume the sysroot will be built in /opt/rpi-sysroot.
 
     export SYSROOT=/opt/rpi-sysroot
@@ -56,7 +63,7 @@ Now, before chrooting into the ARM sysroot, you'll need to apply a workaround,
 edit $SYSROOT/etc/ld.so.preload and comment out all lines in it.
 
     sudo chroot $SYSROOT
-    apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev libxss-dev
+    apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxss-dev
     exit
     sudo umount $SYSROOT/dev
     sudo umount $SYSROOT/proc
@@ -82,9 +89,8 @@ To be able to deploy this to /usr/local in the Raspbian system you need to fix u
 
     perl -w -pi -e "s#$PWD/rpi-sdl2-installed#/usr/local#g;" ./rpi-sdl2-installed/lib/libSDL2.la ./rpi-sdl2-installed/lib/pkgconfig/sdl2.pc ./rpi-sdl2-installed/bin/sdl2-config
 
-================================================================================
 Apps don't work or poor video/audio performance
-================================================================================
+-----------------------------------------------
 
 If you get sound problems, buffer underruns, etc, run "sudo rpi-update" to
 update the RPi's firmware. Note that doing so will fix these problems, but it
@@ -98,17 +104,15 @@ See here how to configure this setting: http://elinux.org/RPiconfig
 Using a fixed gpu_mem=128 is the best option (specially if you updated the
 firmware, using CMA probably won't work, at least it's the current case).
 
-================================================================================
 No input
-================================================================================
+--------
 
 Make sure you belong to the "input" group.
 
     sudo usermod -aG input `whoami`
 
-================================================================================
 No HDMI Audio
-================================================================================
+-------------
 
 If you notice that ALSA works but there's no audio over HDMI, try adding:
 
@@ -118,9 +122,8 @@ to your config.txt file and reboot.
 
 Reference: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5062
 
-================================================================================
 Text Input API support
-================================================================================
+----------------------
 
 The Text Input API is supported, with translation of scan codes done via the
 kernel symbol tables. For this to work, SDL needs access to a valid console.
@@ -136,7 +139,7 @@ your app has read access to one of the following:
 This is usually not a problem if you run from the physical terminal (as opposed
 to running from a pseudo terminal, such as via SSH). If running from a PTS, a
 quick workaround is to run your app as root or add yourself to the tty group,
-then re login to the system.
+then re-login to the system.
 
     sudo usermod -aG tty `whoami`
 
@@ -150,9 +153,9 @@ this determining the CAPS LOCK behavior:
 
     sudo dpkg-reconfigure locales
 
-================================================================================
+
 OpenGL problems
-================================================================================
+---------------
 
 If you have desktop OpenGL headers installed at build time in your RPi or cross
 compilation environment, support for it will be built in. However, the chipset
@@ -167,9 +170,8 @@ environment variable:
 
     export SDL_RENDER_DRIVER=opengles2
 
-================================================================================
 Notes
-================================================================================
+-----
 
 * When launching apps remotely (via SSH), SDL can prevent local keystrokes from
   leaking into the console only if it has root privileges. Launching apps locally

libs/SDL2/docs/README-riscos.md

+RISC OS
+=======
+
+Requirements:
+
+* RISC OS 3.5 or later.
+* [SharedUnixLibrary](http://www.riscos.info/packages/LibraryDetails.html#SharedUnixLibraryarm).
+* [DigitalRenderer](http://www.riscos.info/packages/LibraryDetails.html#DRendererarm), for audio support.
+* [Iconv](http://www.netsurf-browser.org/projects/iconv/), for `SDL_iconv` and related functions.
+
+
+Compiling:
+----------
+
+Currently, SDL2 for RISC OS only supports compiling with GCCSDK under Linux. Both the autoconf and CMake build systems are supported.
+
+The following commands can be used to build SDL2 for RISC OS using autoconf:
+
+    ./configure --host=arm-unknown-riscos --prefix=$GCCSDK_INSTALL_ENV --disable-gcc-atomics
+    make
+    make install
+
+The following commands can be used to build SDL2 for RISC OS using CMake:
+
+    cmake -Bbuild-riscos -DCMAKE_TOOLCHAIN_FILE=$GCCSDK_INSTALL_ENV/toolchain-riscos.cmake -DRISCOS=ON -DCMAKE_INSTALL_PREFIX=$GCCSDK_INSTALL_ENV -DCMAKE_BUILD_TYPE=Release -DSDL_GCC_ATOMICS=OFF
+    cmake --build build-riscos
+    cmake --build build-riscos --target install
+
+
+Current level of implementation
+-------------------------------
+
+The video driver currently provides full screen video support with keyboard and mouse input. Windowed mode is not yet supported, but is planned in the future. Only software rendering is supported.
+
+The filesystem APIs return either Unix-style paths or RISC OS-style paths based on the value of the `__riscosify_control` symbol, as is standard for UnixLib functions.
+
+The audio, loadso, thread and timer APIs are currently provided by UnixLib.
+
+GCC atomics are currently broken on some platforms, meaning it's currently necessary to compile with `--disable-gcc-atomics` using autotools or `-DSDL_GCC_ATOMICS=OFF` using CMake.
+
+The joystick, locale and power APIs are not yet implemented.

libs/SDL2/docs/README-touch.md

@@ -42,14 +42,14 @@ Same as SDL_FINGERDOWN.
 ===========================================================================
 Functions
 ===========================================================================
-SDL provides the ability to access the underlying Finger structures.
+SDL provides the ability to access the underlying SDL_Finger structures.
 These structures should _never_ be modified.
 
 The following functions are included from SDL_touch.h
 
-To get a SDL_TouchID call SDL_GetTouchDevice(index).
+To get a SDL_TouchID call SDL_GetTouchDevice(int index).
 This returns a SDL_TouchID.
-IMPORTANT: If the touch has been removed, or there is no touch with the given ID, SDL_GetTouchID will return 0. Be sure to check for this!
+IMPORTANT: If the touch has been removed, or there is no touch with the given index, SDL_GetTouchDevice() will return 0. Be sure to check for this!
 
 The number of touch devices can be queried with SDL_GetNumTouchDevices().
 
@@ -64,13 +64,13 @@ The most common reason to access SDL_Finger is to query the fingers outside the
 
 
 
-To get a SDL_Finger, call SDL_GetTouchFinger(touchID,index), where touchID is a SDL_TouchID, and index is the requested finger.
+To get a SDL_Finger, call SDL_GetTouchFinger(SDL_TouchID touchID, int index), where touchID is a SDL_TouchID, and index is the requested finger.
 This returns a SDL_Finger *, or NULL if the finger does not exist, or has been removed.
 A SDL_Finger is guaranteed to be persistent for the duration of a touch, but it will be de-allocated as soon as the finger is removed. This occurs when the SDL_FINGERUP event is _added_ to the event queue, and thus _before_ the SDL_FINGERUP event is polled.
 As a result, be very careful to check for NULL return values.
 
 A SDL_Finger has the following fields:
-* x,y,pressure:
+* x, y:
 	The current coordinates of the touch.
 * pressure:
 	The pressure of the touch.