libs/SDL2/docs/README-linux.md

@@ -3,8 +3,8 @@ 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.
 
@@ -12,27 +12,27 @@ default configuration parameters.
 Build Dependencies
 --------------------------------------------------------------------------------
 
-Ubuntu 20.04, all available features enabled:
+Ubuntu 18.04, all available features enabled:
 
-    sudo apt-get install build-essential git make cmake autoconf automake \
-    libtool pkg-config libasound2-dev libpulse-dev libaudio-dev libjack-dev \
-    libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev \
-    libxinerama-dev libxxf86vm-dev libxss-dev libgl1-mesa-dev libdbus-1-dev \
-    libudev-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev \
-    fcitx-libs-dev libsamplerate0-dev libsndio-dev libwayland-dev \
-    libxkbcommon-dev libdrm-dev libgbm-dev
+    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
+
+Ubuntu 22.04+ can also add `libpipewire-0.3-dev libdecor-0-dev` to that command line.
 
 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 libXinerama-devel libXxf86vm-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 pipewire-jack-audio-connection-kit-devel libdecor-devel \
-    libsamplerate-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 and esd, because Ubuntu

libs/SDL2/docs/README-macos.md

@@ -43,15 +43,14 @@ make
 sudo make install
 ```
 
-This script builds SDL with 10.6 ABI compatibility on 64-bit Intel and 11.0
+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.6 systems). PowerPC support for Mac OS X has
-been officially dropped as of SDL 2.0.2. 32-bit Intel, using an older Xcode
-release, is still supported at the time of this writing, but current Xcode
-releases no longer support it, and eventually neither will SDL.
+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.

libs/SDL2/docs/README-macosx.md

-Mac OS X
-==============================================================================
-
-These instructions are for people using Apple's Mac OS X (pronounced
-"ten").
-
-From the developer's point of view, OS X 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
-    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:
-
-    mkdir mybuild
-    cd mybuild
-    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-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
-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.
-
-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:
-
-- 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
-  file with the app. To solve these issues, put the following code in your 
-  NSApplicationDelegate implementation:
-
-
-    - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
-    {
-        if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
-            SDL_Event event;
-            event.type = SDL_QUIT;
-            SDL_PushEvent(&event);
-        }
-    
-        return NSTerminateCancel;
-    }
-    
-    - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
-    {
-        if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
-            SDL_Event event;
-            event.type = SDL_DROPFILE;
-            event.drop.file = SDL_strdup([filename UTF8String]);
-            return (SDL_PushEvent(&event) > 0);
-        }
-    
-        return NO;
-    }
-
-==============================================================================
-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
-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
-"MyCoolGame.app".
-
-To get this build automatically, add something like the following rule to
-your Makefile.am:
-
-    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.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.
-
-If you want the created bundles to be installed, you may want to add this
-rule to your Makefile.am:
-
-    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/".
-
-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
-there are some more things you should do before shipping your product...
-
-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
-
-       sdl-config --static-libs
-
-   instead of those listed by
-
-       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
-   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
-   when you click on the .app, or if you look at the "Get Info" window.
-   More information about Info.plist files can be found on Apple's homepage.
-
-
-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
-the net, so feel free to take a peek at them for inspiration!
-
-
-==============================================================================
-Using the Simple DirectMedia Layer with Xcode
-==============================================================================
-
-These instructions are for using Apple's Xcode IDE to build SDL applications.
-
-- 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:
-
-    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
-
-The SDL Library is packaged as a framework bundle, an organized
-relocatable folder hierarchy of executable code, interface headers,
-and additional resources. For practical purposes, you can think of a 
-framework as a more user and system-friendly shared library, whose library
-file behaves more or less like a standard UNIX shared library.
-
-To build the framework, simply open the framework project and build it. 
-By default, the framework bundle "SDL.framework" is installed in 
-/Library/Frameworks. Therefore, the testers and project stationary expect
-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
-
-- 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
-    Open the SDLTest project and build away!
-
-- 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
-    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
-    * 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
-
-- 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.
-    
-- 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!
-        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.
-        You are free to modify your Cocoa app with generally no consequence 
-        to SDL. You cannot, however, easily change the SDL window itself.
-        Functionality may be added in the future to help this.
-
-
-Known bugs are listed in the file "BUGS.txt".

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

@@ -3,7 +3,7 @@ Simple DirectMedia Layer 2 for OS/2 & eComStation
 SDL port for OS/2, authored by Andrey Vasilkin <digi@os2.snc.ru>, 2016
 
 
-OpenGL and audio capture not supported by this port.
+OpenGL not supported by this port.
 
 Additional optional environment variables:
 

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 SDL2 library 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)
 
-Getting PSP toolchain
----------------------
-https://github.com/pspdev/psptoolchain
+[Build Instructions](https://github.com/hrydgard/ppsspp/wiki/Build-instructions)
 
-Running on PPSSPP Emulator
---------------------------
-https://github.com/hrydgard/ppsspp
-( https://github.com/hrydgard/ppsspp/wiki/Build-instructions )
 
-Compiling an HelloWorld
------------------------
-https://psp-dev.org/doku.php?id=tutorial:hello_world
+## 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

@@ -63,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

libs/SDL2/docs/README-versions.md

+# Versioning
+
+## Since 2.23.0
+
+SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak
+and older versions of the Linux kernel:
+
+* The major version (first part) increases when backwards compatibility
+    is broken, which will happen infrequently.
+
+* If the minor version (second part) is divisible by 2
+    (for example 2.24.x, 2.26.x), this indicates a version of SDL that
+    is believed to be stable and suitable for production use.
+
+    * In stable releases, the patchlevel or micro version (third part)
+        indicates bugfix releases. Bugfix releases should not add or
+        remove ABI, so the ".0" release (for example 2.24.0) should be
+        forwards-compatible with all the bugfix releases from the
+        same cycle (for example 2.24.1).
+
+    * The minor version increases when new API or ABI is added, or when
+        other significant changes are made. Newer minor versions are
+        backwards-compatible, but not fully forwards-compatible.
+        For example, programs built against SDL 2.24.x should work fine
+        with SDL 2.26.x, but programs built against SDL 2.26.x will not
+        necessarily work with 2.24.x.
+
+* If the minor version (second part) is not divisible by 2
+    (for example 2.23.x, 2.25.x), this indicates a development prerelease
+    of SDL that is not suitable for stable software distributions.
+    Use with caution.
+
+    * The patchlevel or micro version (third part) increases with
+        each prerelease.
+
+    * Each prerelease might add new API and/or ABI.
+
+    * Prereleases are backwards-compatible with older stable branches.
+        For example, 2.25.x will be backwards-compatible with 2.24.x.
+
+    * Prereleases are not guaranteed to be backwards-compatible with
+        each other. For example, new API or ABI added in 2.25.1
+        might be removed or changed in 2.25.2.
+        If this would be a problem for you, please do not use prereleases.
+
+    * Only upgrade to a prerelease if you can guarantee that you will
+        promptly upgrade to the stable release that follows it.
+        For example, do not upgrade to 2.23.x unless you will be able to
+        upgrade to 2.24.0 when it becomes available.
+
+    * Software distributions that have a freeze policy (in particular Linux
+        distributions with a release cycle, such as Debian and Fedora)
+        should usually only package stable releases, and not prereleases.
+
+## Before 2.23.0
+
+Older versions of SDL followed a similar policy, but instead of the
+odd/even rule applying to the minor version, it applied to the patchlevel
+(micro version, third part). For example, 2.0.22 was a stable release
+and 2.0.21 was a prerelease.

libs/SDL2/docs/README-visualc.md

 Using SDL with Microsoft Visual C++
 ===================================
 
-### by [Lion Kimbro](mailto:snowlion@sprynet.com) with additions by [James Turk](mailto:james@conceptofzero.net)
+### by Lion Kimbro with additions by James Turk
 
 You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
 yourself.

libs/SDL2/docs/README-vita.md

@@ -3,7 +3,7 @@ PS Vita
 SDL port for the Sony Playstation Vita and Sony Playstation TV
 
 Credit to
-* xerpi and rsn8887 for initial (vita2d) port
+* xerpi, cpasjuste and rsn8887 for initial (vita2d) port
 * vitasdk/dolcesdk devs
 * CBPS discord (Namely Graphene and SonicMastr)
 
@@ -22,6 +22,9 @@ Notes
 * gles1/gles2 support and renderers are disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PVR=ON`
   These renderers support 720p and 1080i resolutions. These can be specified with:
   `SDL_setenv("VITA_RESOLUTION", "720", 1);` and `SDL_setenv("VITA_RESOLUTION", "1080", 1);`
+* Desktop GL 1.X and 2.X support and renderers are also disabled by default and also can be enabled with `-DVIDEO_VITA_PVR=ON` as long as gl4es4vita is present in your SDK.
+  They support the same resolutions as the gles1/gles2 backends and require specifying `SDL_setenv("VITA_PVR_OGL", "1", 1);`
+  anytime before video subsystem initialization.
 * gles2 support via PIB is disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PIB=ON`
 * By default SDL emits mouse events for touch events on every touchscreen.
   Vita has two touchscreens, so it's recommended to use `SDL_SetHint(SDL_HINT_TOUCH_MOUSE_EVENTS, "0");` and handle touch events instead.

libs/SDL2/docs/README-windows.md

-Windows
-================================================================================
+# Windows
 
-================================================================================
-OpenGL ES 2.x support
-================================================================================
+## LLVM and Intel C++ compiler support
+
+SDL will build with the Visual Studio project files with LLVM-based compilers, such as the Intel oneAPI C++
+compiler, but you'll have to manually add the "-msse3" command line option
+to at least the SDL_audiocvt.c source file, and possibly others. This may
+not be necessary if you build SDL with CMake instead of the included Visual
+Studio solution.
+
+Details are here: https://github.com/libsdl-org/SDL/issues/5186
+
+
+## OpenGL ES 2.x support
 
 SDL has support for OpenGL ES 2.x under Windows via two alternative
 implementations.
+
 The most straightforward method consists in running your app in a system with
 a graphic card paired with a relatively recent (as of November of 2013) driver
 which supports the WGL_EXT_create_context_es2_profile extension. Vendors known
 to ship said extension on Windows currently include nVidia and Intel.
 
-The other method involves using the ANGLE library (https://code.google.com/p/angleproject/)
-If an OpenGL ES 2.x context is requested and no WGL_EXT_create_context_es2_profile
-extension is found, SDL will try to load the libEGL.dll library provided by
-ANGLE.
+The other method involves using the
+[ANGLE library](https://code.google.com/p/angleproject/). If an OpenGL ES 2.x
+context is requested and no WGL_EXT_create_context_es2_profile extension is
+found, SDL will try to load the libEGL.dll library provided by ANGLE.
+
 To obtain the ANGLE binaries, you can either compile from source from
-https://chromium.googlesource.com/angle/angle or copy the relevant binaries from
-a recent Chrome/Chromium install for Windows. The files you need are:
+https://chromium.googlesource.com/angle/angle or copy the relevant binaries
+from a recent Chrome/Chromium install for Windows. The files you need are:
 
-    * libEGL.dll
-    * libGLESv2.dll
-    * d3dcompiler_46.dll (supports Windows Vista or later, better shader compiler)
-    or...
-    * d3dcompiler_43.dll (supports Windows XP or later)
+- libEGL.dll
+- libGLESv2.dll
+- d3dcompiler_46.dll (supports Windows Vista or later, better shader
+  compiler) *or* d3dcompiler_43.dll (supports Windows XP or later)
 
 If you compile ANGLE from source, you can configure it so it does not need the
 d3dcompiler_* DLL at all (for details on this, see their documentation).
 However, by default SDL will try to preload the d3dcompiler_46.dll to
-comply with ANGLE's requirements. If you wish SDL to preload d3dcompiler_43.dll (to
-support Windows XP) or to skip this step at all, you can use the 
-SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more details).
+comply with ANGLE's requirements. If you wish SDL to preload
+d3dcompiler_43.dll (to support Windows XP) or to skip this step at all, you
+can use the SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more
+details).
 
 Known Bugs:
 
-    * SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
+- SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
   that there's a bug in the library which prevents the window contents from
   refreshing if this is set to anything other than the default value.
 
-Vulkan Surface Support
-==============
+## Vulkan Surface Support
+
+Support for creating Vulkan surfaces is configured on by default. To disable
+it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You
+must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to
+use Vulkan graphics in your application.
 
-Support for creating Vulkan surfaces is configured on by default. To disable it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to use Vulkan graphics in your application.

libs/SDL2/docs/README-winrt.md

@@ -5,47 +5,21 @@ This port allows SDL applications to run on Microsoft's platforms that require
 use of "Windows Runtime", aka. "WinRT", APIs.  Microsoft may, in some cases,
 refer to them as either "Windows Store", or for Windows 10, "UWP" apps.
 
-Some of the operating systems that include WinRT, are:
-
-* Windows 10, via its Universal Windows Platform (UWP) APIs
-* Windows 8.x
-* Windows RT 8.x (aka. Windows 8.x for ARM processors)
-* Windows Phone 8.x
+In the past, SDL has supported Windows RT 8.x, Windows Phone, etc, but in
+modern times this port is focused on UWP apps, which run on Windows 10,
+and modern Xbox consoles.
 
 
 Requirements
 ------------
 
-* Microsoft Visual C++ (aka Visual Studio), either 2017, 2015, 2013, or 2012
+* Microsoft Visual C++ (aka Visual Studio) 2019.
   - Free, "Community" or "Express" editions may be used, so long as they
     include support for either "Windows Store" or "Windows Phone" apps.
     "Express" versions marked as supporting "Windows Desktop" development
     typically do not include support for creating WinRT apps, to note.
     (The "Community" editions of Visual C++ do, however, support both
     desktop/Win32 and WinRT development).
-  - Visual Studio 2017 can be used, however it is recommended that you install
-    the Visual C++ 2015 build tools.  These build tools can be installed
-    using VS 2017's installer.  Be sure to also install the workload for
-    "Universal Windows Platform development", its optional component, the
-    "C++ Universal Windows Platform tools", and for UWP / Windows 10
-    development, the "Windows 10 SDK (10.0.10240.0)".  Please note that
-    targeting UWP / Windows 10 apps from development machine(s) running
-    earlier versions of Windows, such as Windows 7, is not always supported
-    by Visual Studio, and you may get error(s) when attempting to do so.
-  - Visual C++ 2012 can only build apps that target versions 8.0 of Windows,
-    or  Windows Phone.  8.0-targeted apps will run on devices running 8.1
-    editions of Windows, however they will not be able to take advantage of
-    8.1-specific features.
-  - Visual C++ 2013 cannot create app projects that target Windows 8.0.
-    Visual C++ 2013 Update 4, can create app projects for Windows Phone 8.0,
-    Windows Phone 8.1, and Windows 8.1, but not Windows 8.0.  An optional
-    Visual Studio add-in, "Tools for Maintaining Store apps for Windows 8",
-    allows Visual C++ 2013 to load and build Windows 8.0 projects that were
-    created with Visual C++ 2012, so long as Visual C++ 2012 is installed
-    on the same machine.  More details on targeting different versions of
-    Windows can found at the following web pages:
-      - [Develop apps by using Visual Studio 2013](http://msdn.microsoft.com/en-us/library/windows/apps/br211384.aspx)
-      - [To add the Tools for Maintaining Store apps for Windows 8](http://msdn.microsoft.com/en-us/library/windows/apps/dn263114.aspx#AddMaintenanceTools)
 * A valid Microsoft account - This requirement is not imposed by SDL, but
   rather by Microsoft's Visual C++ toolchain.  This is required to launch or
   debug apps.
@@ -57,7 +31,7 @@ Status
 Here is a rough list of what works, and what doesn't:
 
 * What works:
-  * compilation via Visual C++ 2012 through 2015
+  * compilation via Visual C++ 2019.
   * compile-time platform detection for SDL programs.  The C/C++ #define,
     `__WINRT__`, will be set to 1 (by SDL) when compiling for WinRT.
   * GPU-accelerated 2D rendering, via SDL_Renderer.
@@ -234,13 +208,8 @@ To set this up for SDL/WinRT, you'll need to run through the following steps:
    "Solution Explorer")
 2. right click on your app's solution.
 3. navigate to "Add", then to "Existing Project..."
-4. find SDL/WinRT's Visual C++ project file and open it.  Different project
-   files exist for different WinRT platforms.  All of them are in SDL's
-   source distribution, in the following directories:
-    * `VisualC-WinRT/UWP_VS2015/`        - for Windows 10 / UWP apps
-    * `VisualC-WinRT/WinPhone81_VS2013/` - for Windows Phone 8.1 apps
-    * `VisualC-WinRT/WinRT80_VS2012/`    - for Windows 8.0 apps
-    * `VisualC-WinRT/WinRT81_VS2013/`    - for Windows 8.1 apps
+4. find SDL/WinRT's Visual C++ project file and open it, in the `VisualC-WinRT`
+   directory.
 5. once the project has been added, right-click on your app's project and
    select, "References..."
 6. click on the button titled, "Add New Reference..."

libs/SDL2/docs/README.md

-Simple DirectMedia Layer {#mainpage}
-========================
+# Simple DirectMedia Layer
 
-                                  (SDL)
-
-                                Version 2.0
-
----
-http://www.libsdl.org/
+https://www.libsdl.org/
 
 Simple DirectMedia Layer is a cross-platform development library designed
 to provide low level access to audio, keyboard, mouse, joystick, and graphics
@@ -14,7 +8,7 @@ hardware via OpenGL and Direct3D. It is used by video playback software,
 emulators, and popular games including Valve's award winning catalog
 and many Humble Bundle games.
 
-SDL officially supports Windows, Mac OS X, Linux, iOS, and Android.
+SDL officially supports Windows, macOS, Linux, iOS, and Android.
 Support for other platforms may be found in the source code.
 
 SDL is written in C, works natively with C++, and there are bindings 
@@ -34,23 +28,27 @@ More documentation and FAQs are available online at [the wiki](http://wiki.libsd
 - [DirectFB](README-directfb.md)
 - [DynAPI](README-dynapi.md)
 - [Emscripten](README-emscripten.md)
+- [GDK](README-gdk.md)
 - [Gesture](README-gesture.md)
 - [Git](README-git.md)
 - [iOS](README-ios.md)
 - [Linux](README-linux.md)
-- [OS X](README-macosx.md)
+- [macOS](README-macos.md)
 - [OS/2](README-os2.md)
 - [Native Client](README-nacl.md)
 - [Pandora](README-pandora.md)
 - [Supported Platforms](README-platforms.md)
 - [Porting information](README-porting.md)
 - [PSP](README-psp.md)
+- [PS2](README-ps2.md)
 - [Raspberry Pi](README-raspberrypi.md)
 - [Touch](README-touch.md)
+- [Versions](README-versions.md)
 - [WinCE](README-wince.md)
 - [Windows](README-windows.md)
 - [WinRT](README-winrt.md)
 - [PSVita](README-vita.md)
+- [Nokia N-Gage](README-ngage.md)
 
 If you need help with the library, or just want to discuss SDL related
 issues, you can join the [SDL Discourse](https://discourse.libsdl.org/),

libs/SDL2/docs/doxyfile

@@ -640,6 +640,7 @@ EXCLUDE                = ../include/SDL_opengles2_gl2ext.h \
                          ../include/SDL_opengles.h \
                          ../include/SDL_opengl.h \
                          ../include/SDL_egl.h \
+                         ./release_checklist.md \
 
 
 # The EXCLUDE_SYMLINKS tag can be used select whether or not files or 

libs/SDL2/docs/release_checklist.md

+# Release checklist
+
+When changing the version, run `build-scripts/update-version.sh X Y Z`,
+where `X Y Z` are the major version, minor version, and patch level. So
+`2 28 1` means "change the version to 2.28.1". This script does much of the
+mechanical work.
+
+
+## New feature release
+
+* Update `WhatsNew.txt`
+
+* Bump version number to 2.EVEN.0:
+
+    * `./build-scripts/update-version.sh 2 EVEN 0`
+
+* Do the release
+
+* Update the website file include/header.inc.php to reflect the new version
+
+## New bugfix release
+
+* Check that no new API/ABI was added
+
+    * If it was, do a new feature release (see above) instead
+
+* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is even)
+
+    * `./build-scripts/update-version.sh 2 Y Z+1`
+
+* Do the release
+
+* Update the website file include/header.inc.php to reflect the new version
+
+## After a feature release
+
+* Create a branch like `release-2.24.x`
+
+* Bump version number to 2.ODD.0 for next development branch
+
+    * `./build-scripts/update-version.sh 2 ODD 0`
+
+## New development prerelease
+
+* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is odd)
+
+    * `./build-scripts/update-version.sh 2 Y Z+1`
+
+* Do the release