Sync wiki -> headers.

docs/README-.md

@@ -0,0 +1,6 @@
+#
+
+<!-- BEGIN CATEGORY LIST -->
+- [raspberrypi](raspberrypi)
+<!-- END CATEGORY LIST -->
+

docs/README-android.md

@@ -26,9 +26,9 @@ How the port works
 ================================================================================
 
 - Android applications are Java-based, optionally with parts written in C
-- As SDL apps are C-based, we use a small Java shim that uses JNI to talk to 
+- As SDL apps are C-based, we use a small Java shim that uses JNI to talk to
   the SDL library
-- This means that your application C code must be placed inside an Android 
+- This means that your application C code must be placed inside an Android
   Java project, along with some C support code that communicates with Java
 - This eventually produces a standard Android .apk package
 
@@ -69,7 +69,7 @@ done in the build directory for the app!
 
 
 For more complex projects, follow these instructions:
-    
+
 1. Copy the android-project directory wherever you want to keep your projects
    and rename it to the name of your project.
 2. Move or symlink this SDL directory into the "<project>/app/jni" directory
@@ -132,15 +132,15 @@ Here's an example of a minimal class file:
 
     --- MyGame.java --------------------------
     package com.gamemaker.game;
-    
-    import org.libsdl.app.SDLActivity; 
-    
+
+    import org.libsdl.app.SDLActivity;
+
     /**
-     * A sample wrapper class that just calls SDLActivity 
-     */ 
-    
+     * A sample wrapper class that just calls SDLActivity
+     */
+
     public class MyGame extends SDLActivity { }
-    
+
     ------------------------------------------
 
 Then replace "SDLActivity" in AndroidManifest.xml with the name of your
@@ -179,7 +179,7 @@ may want to keep this fact in mind when building your APK, specially when large
 files are involved.
 For more information on which extensions get compressed by default and how to
 disable this behaviour, see for example:
-    
+
 http://ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps/
 
 
@@ -350,7 +350,7 @@ I get output from addr2line showing that it's in the quit function, in testsprit
 You can add logging to your code to help show what's happening:
 
     #include <android/log.h>
-    
+
     __android_log_print(ANDROID_LOG_INFO, "foo", "Something happened! x = %d", x);
 
 If you need to build without optimization turned on, you can create a file called
@@ -440,7 +440,7 @@ where you only update a portion of the screen on each frame, you may notice a
 variety of visual glitches on Android, that are not present on other platforms.
 This is caused by SDL's use of EGL as the support system to handle OpenGL ES/ES2
 contexts, in particular the use of the eglSwapBuffers function. As stated in the
-documentation for the function "The contents of ancillary buffers are always 
+documentation for the function "The contents of ancillary buffers are always
 undefined after calling eglSwapBuffers".
 Setting the EGL_SWAP_BEHAVIOR attribute of the surface to EGL_BUFFER_PRESERVED
 is not possible for SDL as it requires EGL 1.4, available only on the API level
@@ -459,7 +459,7 @@ Two legitimate ways:
 Activity by calling Activity.finish().
 
 - Android OS can decide to terminate your application by calling onDestroy()
-(see Activity life cycle). Your application will receive a SDL_QUIT event you 
+(see Activity life cycle). Your application will receive a SDL_QUIT event you
 can handle to save things and quit.
 
 Don't call exit() as it stops the activity badly.

docs/README-cmake.md

@@ -3,10 +3,10 @@
 (www.cmake.org)
 
 SDL's build system was traditionally based on autotools. Over time, this
-approach has suffered from several issues across the different supported 
+approach has suffered from several issues across the different supported
 platforms.
 To solve these problems, a new build system based on CMake was introduced.
-It is developed in parallel to the legacy autotools build system, so users 
+It is developed in parallel to the legacy autotools build system, so users
 can experiment with it without complication.
 
 The CMake build system is supported on the following platforms:
@@ -59,15 +59,15 @@ if(MYGAME_VENDORED)
 else()
     # 1. Look for a SDL2 package, 2. look for the SDL2 component and 3. fail if none can be found
     find_package(SDL2 REQUIRED CONFIG REQUIRED COMPONENTS SDL2)
-    
-    # 1. Look for a SDL2 package, 2. Look for the SDL2maincomponent and 3. DO NOT fail when SDL2main is not available 
+
+    # 1. Look for a SDL2 package, 2. Look for the SDL2maincomponent and 3. DO NOT fail when SDL2main is not available
     find_package(SDL2 REQUIRED CONFIG COMPONENTS SDL2main)
 endif()
 
-# Create your game executable target as usual 
+# Create your game executable target as usual
 add_executable(mygame WIN32 mygame.c)
 
-# SDL2::SDL2main may or may not be available. It is e.g. required by Windows GUI applications  
+# SDL2::SDL2main may or may not be available. It is e.g. required by Windows GUI applications
 if(TARGET SDL2::SDL2main)
     # It has an implicit dependency on SDL2 functions, so it MUST be added before SDL2::SDL2 (or SDL2::SDL2-static)
     target_link_libraries(mygame PRIVATE SDL2::SDL2main)

docs/README-directfb.md

@@ -12,7 +12,7 @@ Supports:
 What you need:
 
 * DirectFB 1.0.1, 1.2.x, 1.3.0
-* Kernel-Framebuffer support: required: vesafb, radeonfb .... 
+* Kernel-Framebuffer support: required: vesafb, radeonfb ....
 * Mesa 7.0.x	   - optional for OpenGL
 
 The `/etc/directfbrc` file should contain the following lines to make
@@ -44,7 +44,7 @@ To use hardware accelerated YUV-overlays for YUV-textures, use:
 export SDL_DIRECTFB_YUV_DIRECT=1
 ```
 
-This is disabled by default. It will only support one 
+This is disabled by default. It will only support one
 YUV texture, namely the first. Every other YUV texture will be
 rendered in software.
 
@@ -84,18 +84,18 @@ As of this writing 20100802 you need to pull Mesa from git and do the following:
 
 ```
 git clone git://anongit.freedesktop.org/git/mesa/mesa
-cd mesa 
+cd mesa
 git checkout 2c9fdaf7292423c157fc79b5ce43f0f199dd753a
 ```
 
 Edit `configs/linux-directfb` so that the Directories-section looks like this:
 
 ```
 # Directories
-SRC_DIRS     = mesa glu 
+SRC_DIRS     = mesa glu
 GLU_DIRS     = sgi
 DRIVER_DIRS  = directfb
-PROGRAM_DIRS = 
+PROGRAM_DIRS =
 ```
 
 Then do the following:

docs/README-dynapi.md

@@ -4,29 +4,29 @@ Originally posted on Ryan's Google+ account.
 
 Background:
 
-- The Steam Runtime has (at least in theory) a really kick-ass build of SDL2, 
-  but developers are shipping their own SDL2 with individual Steam games. 
-  These games might stop getting updates, but a newer SDL2 might be needed later. 
-  Certainly we'll always be fixing bugs in SDL, even if a new video target isn't 
+- The Steam Runtime has (at least in theory) a really kick-ass build of SDL2,
+  but developers are shipping their own SDL2 with individual Steam games.
+  These games might stop getting updates, but a newer SDL2 might be needed later.
+  Certainly we'll always be fixing bugs in SDL, even if a new video target isn't
   ever needed, and these fixes won't make it to a game shipping its own SDL.
-- Even if we replace the SDL2 in those games with a compatible one, that is to 
-  say, edit a developer's Steam depot (yuck!), there are developers that are 
-  statically linking SDL2 that we can't do this for. We can't even force the 
+- Even if we replace the SDL2 in those games with a compatible one, that is to
+  say, edit a developer's Steam depot (yuck!), there are developers that are
+  statically linking SDL2 that we can't do this for. We can't even force the
   dynamic loader to ignore their SDL2 in this case, of course.
 - If you don't ship an SDL2 with the game in some form, people that disabled the
-  Steam Runtime, or just tried to run the game from the command line instead of 
+  Steam Runtime, or just tried to run the game from the command line instead of
   Steam might find themselves unable to run the game, due to a missing dependency.
 - If you want to ship on non-Steam platforms like GOG or Humble Bundle, or target
-  generic Linux boxes that may or may not have SDL2 installed, you have to ship 
-  the library or risk a total failure to launch. So now, you might have to have 
-  a non-Steam build plus a Steam build (that is, one with and one without SDL2 
-  included), which is inconvenient if you could have had one universal build 
+  generic Linux boxes that may or may not have SDL2 installed, you have to ship
+  the library or risk a total failure to launch. So now, you might have to have
+  a non-Steam build plus a Steam build (that is, one with and one without SDL2
+  included), which is inconvenient if you could have had one universal build
   that works everywhere.
-- We like the zlib license, but the biggest complaint from the open source 
-  community about the license change is the static linking. The LGPL forced this 
+- We like the zlib license, but the biggest complaint from the open source
+  community about the license change is the static linking. The LGPL forced this
   as a legal, not technical issue, but zlib doesn't care. Even those that aren't
-  concerned about the GNU freedoms found themselves solving the same problems: 
-  swapping in a newer SDL to an older game often times can save the day. 
+  concerned about the GNU freedoms found themselves solving the same problems:
+  swapping in a newer SDL to an older game often times can save the day.
   Static linking stops this dead.
 
 So here's what we did:
@@ -45,7 +45,7 @@ Except that is all done with a bunch of macro magic so we don't have to maintain
 every one of these.
 
 What is jump_table.SDL_init()? Eventually, that's a function pointer of the real
-SDL_Init() that you've been calling all this time. But at startup, it looks more 
+SDL_Init() that you've been calling all this time. But at startup, it looks more
 like this:
 
 ```c
@@ -56,83 +56,83 @@ Uint32 SDL_Init_DEFAULT(Uint32 flags)
 }
 ```
 
-SDL_InitDynamicAPI() fills in jump_table with all the actual SDL function 
-pointers, which means that this `_DEFAULT` function never gets called again. 
+SDL_InitDynamicAPI() fills in jump_table with all the actual SDL function
+pointers, which means that this `_DEFAULT` function never gets called again.
 First call to any SDL function sets the whole thing up.
 
 So you might be asking, what was the value in that? Isn't this what the operating
-system's dynamic loader was supposed to do for us? Yes, but now we've got this 
+system's dynamic loader was supposed to do for us? Yes, but now we've got this
 level of indirection, we can do things like this:
 
 ```bash
 export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
 ./MyGameThatIsStaticallyLinkedToSDL2
 ```
 
-And now, this game that is statically linked to SDL, can still be overridden 
-with a newer, or better, SDL. The statically linked one will only be used as 
+And now, this game that is statically linked to SDL, can still be overridden
+with a newer, or better, SDL. The statically linked one will only be used as
 far as calling into the jump table in this case. But in cases where no override
-is desired, the statically linked version will provide its own jump table, 
+is desired, the statically linked version will provide its own jump table,
 and everyone is happy.
 
 So now:
-- Developers can statically link SDL, and users can still replace it. 
+- Developers can statically link SDL, and users can still replace it.
   (We'd still rather you ship a shared library, though!)
-- Developers can ship an SDL with their game, Valve can override it for, say, 
-  new features on SteamOS, or distros can override it for their own needs, 
+- Developers can ship an SDL with their game, Valve can override it for, say,
+  new features on SteamOS, or distros can override it for their own needs,
   but it'll also just work in the default case.
-- Developers can ship the same package to everyone (Humble Bundle, GOG, etc), 
+- Developers can ship the same package to everyone (Humble Bundle, GOG, etc),
   and it'll do the right thing.
-- End users (and Valve) can update a game's SDL in almost any case, 
+- End users (and Valve) can update a game's SDL in almost any case,
   to keep abandoned games running on newer platforms.
-- Everyone develops with SDL exactly as they have been doing all along. 
+- Everyone develops with SDL exactly as they have been doing all along.
   Same headers, same ABI. Just get the latest version to enable this magic.
 
 
 A little more about SDL_InitDynamicAPI():
 
-Internally, InitAPI does some locking to make sure everything waits until a 
-single thread initializes everything (although even SDL_CreateThread() goes 
+Internally, InitAPI does some locking to make sure everything waits until a
+single thread initializes everything (although even SDL_CreateThread() goes
 through here before spinning a thread, too), and then decides if it should use
-an external SDL library. If not, it sets up the jump table using the current 
+an external SDL library. If not, it sets up the jump table using the current
 SDL's function pointers (which might be statically linked into a program, or in
-a shared library of its own). If so, it loads that library and looks for and 
+a shared library of its own). If so, it loads that library and looks for and
 calls a single function:
 
 ```c
 SInt32 SDL_DYNAPI_entry(Uint32 version, void *table, Uint32 tablesize);
 ```
 
 That function takes a version number (more on that in a moment), the address of
-the jump table, and the size, in bytes, of the table. 
-Now, we've got policy here: this table's layout never changes; new stuff gets 
-added to the end. Therefore SDL_DYNAPI_entry() knows that it can provide all 
+the jump table, and the size, in bytes, of the table.
+Now, we've got policy here: this table's layout never changes; new stuff gets
+added to the end. Therefore SDL_DYNAPI_entry() knows that it can provide all
 the needed functions if tablesize <= sizeof its own jump table. If tablesize is
 bigger (say, SDL 2.0.4 is trying to load SDL 2.0.3), then we know to abort, but
 if it's smaller, we know we can provide the entire API that the caller needs.
 
-The version variable is a failsafe switch. 
-Right now it's always 1. This number changes when there are major API changes 
-(so we know if the tablesize might be smaller, or entries in it have changed). 
-Right now SDL_DYNAPI_entry gives up if the version doesn't match, but it's not 
-inconceivable to have a small dispatch library that only supplies this one 
+The version variable is a failsafe switch.
+Right now it's always 1. This number changes when there are major API changes
+(so we know if the tablesize might be smaller, or entries in it have changed).
+Right now SDL_DYNAPI_entry gives up if the version doesn't match, but it's not
+inconceivable to have a small dispatch library that only supplies this one
 function and loads different, otherwise-incompatible SDL libraries and has the
-right one initialize the jump table based on the version. For something that 
-must generically catch lots of different versions of SDL over time, like the 
+right one initialize the jump table based on the version. For something that
+must generically catch lots of different versions of SDL over time, like the
 Steam Client, this isn't a bad option.
 
 Finally, I'm sure some people are reading this and thinking,
-"I don't want that overhead in my project!"  
+"I don't want that overhead in my project!"
 
-To which I would point out that the extra function call through the jump table 
-probably wouldn't even show up in a profile, but lucky you: this can all be 
-disabled. You can build SDL without this if you absolutely must, but we would 
-encourage you not to do that. However, on heavily locked down platforms like 
+To which I would point out that the extra function call through the jump table
+probably wouldn't even show up in a profile, but lucky you: this can all be
+disabled. You can build SDL without this if you absolutely must, but we would
+encourage you not to do that. However, on heavily locked down platforms like
 iOS, or maybe when debugging, it makes sense to disable it. The way this is
-designed in SDL, you just have to change one #define, and the entire system 
-vaporizes out, and SDL functions exactly like it always did. Most of it is 
-macro magic, so the system is contained to one C file and a few headers. 
-However, this is on by default and you have to edit a header file to turn it 
-off. Our hopes is that if we make it easy to disable, but not too easy, 
-everyone will ultimately be able to get what they want, but we've gently 
+designed in SDL, you just have to change one #define, and the entire system
+vaporizes out, and SDL functions exactly like it always did. Most of it is
+macro magic, so the system is contained to one C file and a few headers.
+However, this is on by default and you have to edit a header file to turn it
+off. Our hopes is that if we make it easy to disable, but not too easy,
+everyone will ultimately be able to get what they want, but we've gently
 nudged everyone towards what we think is the best solution.