Test apps in Xcode-iOS/Test/TestiPhoneOS.xcodeproj weren't launching
in the most-recent release of Xcode and the iOS Simulator (version 11.3.1).
This was caused by their shared Info.plist file not defining a
CFBundleShortVersionString (as reported by Xcode, when launching a test
app from within Xcode).
This is a multi-part fix, and is the 2nd attempt at a fix for Bug 5034. Here
are the problems being addressed:
1. On macOS 10.14.x and earlier, trying to call IOHIDDeviceUnscheduleFromRunLoop
without a prior, paired call to IOHIDDeviceScheduleWithRunLoop, appears to
lead to a crash. A per-device flag has been added to make sure that these
calls are paired.
2. DARWIN_JoystickDetect was free'ing its SDL_joystick's hwdata field
(via FreeDevice) without setting it to NULL, and DARWIN_JoystickRumble wasn't
checking for a NULL hwdata. FreeDevice will now set hwdata to NULL and
DARWIN_JoystickRumble will check for a NULL hwdata.
This fixes a crash whereby SDL could crash on macOS/Darwin, if and when a
USB game controller gets unplugged. SDL was not retaining a reference
to the controller's OS/IOKit-provided 'device object', and was capable
of trying to use it, after a device was hot-unplugged.
This fills in the CFBundleVersion and CFBundleShortVersionString fields,
if and when SDL's test-apps are built via CMake. This is needed to install
the .app bundles on iOS 13+ (using 'xcrun simctl install booted path/to/testsuchandsuch.app')
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=tvOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: appletvos, appletvsimulator, appletvos12.4, /full/path/to/AppleTVOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;x86_64")
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
This also seems to fix the follow-up issue in bug #3719, whereby the initial fix caused the SDL window to move, after transitioning from fullscreen to windowed-mode
According to Steam's OS stats, Windows 8.0 use is pretty much nil. Further,
Microsoft hasn't support Windows 8.0 development in any of their
actively-updated toolchains, and setting it up can be a pain.
In theory, SDL2 still supports Windows 8.0, however building of Windows 8.0
.dlls is no longer the default, if and when using the 'winrtbuild.*' scripts.
The MSVC 2012 project files for building Windows 8.0 dlls remain, though,
for the time being.
These fixes are lumped into two categories:
1. add new file, SDL_dataqueue.c, to UWP/WinRT build-inputs (via MSVC project
files)
2. implement a temporary, hack-fix for a build error in SDL_xinputjoystick.c.
Win32's Raw Input APIs are, unfortunately, not available for use in UWP/WinRT
APIs. There does appear to be a replacement API, available in the
Windows.Devices.HumanInterfaceDevice namespace.
This fix should be sufficient to get SDL compiling again, without affecting
Win32 builds, however using the UWP/WinRT API (in UWP/WinRT builds) would
almost certainly be better (for UWP/WinRT builds).
TODO: research Windows.Devices.HumanInterfaceDevice, and use that if and as
appropriate.
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
This workaround, unfortunately, requires that apps directly link to a set of
Win32-style cursor resource files (that contain a transparent cursor image).
Copies of suitable resource files are in src/core/winrt/, and should be
included directly in an app's MSVC project.
A rough explanation of this workaround/hack, and why it's needed (and
seemingly can't be done through programmatic means), is in this change's code.
Win10's 'GamepadAdded' event seems to need to have something registered with it
in order for Xinput-based gamepad detection to work. This 'fix' simply causes
a dummy event-handler to be added for this event, in case an app wants to use
gamepads on Xbox One (most likely).
DXGI fails to report any displays in at least one of the
"Windows App Certification Kit 10.0"'s tests for Store Apps. This was
causing SDL's video initialization code to fail, when the suspect test
("Direct3D Feature Test") was run, as DXGI was unable to report a
display-output at adapter-index 0, output-index 0.
The workaround that is applied here attempts to detect this case, then
use a hopefully-reasonable alternative means to calculate at least one
display output.
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created
thread's priority. WinRT 8.1 offered this API, along with several other
Win32 thread functions that were previously unavailable (in WinRT).
This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
This change integrates initialization settings for ANGLE/WinRT, as suggested in
MSOpenTech's latest ANGLE template-projects (for MSVC).
This should fix some OpenGL initialization issues on WinPhone 8.1 on ARM, and
on the 1st-generation Surface RT.
Windows Phone does not appear to allow VSync to be turned off. Doing so appears
to either result in content not getting drawn (when the D3D debug runtime is
turned off), or forcing VSync back on and logging an error (when the D3D debug
runtime is turned on).
VSync had been getting turned on anyways, this change just notes such:
- via the WinRT README
- by always setting the SDL_RENDERER_PRESENTVSYNC flag when creating an
SDL_Renderer on Windows Phone
SDL_WinRTRunApp() is used on WinRT to launch a main(int, char **)-style
function. It has optional, and experimental support for launching content
inside a XAML control, backed by a main() function running on a separate thread.
This is provided via it's 2nd parameter, which can be a pointer to a XAML
control. (If NULL, XAML support will not be used.)
This change renames the experimental feature's parameter (to SDL_WinRTRunApp())
as "reserved", until such time as the functionality is ready for use. It will
likely be renamed again in the future, when running SDL on top of a XAML control
via a separate thread, becomes reasonably usable.
This is a Win32-specific fix for bug 2726. A WinRT fix for this bug was applied
separately, via https://hg.libsdl.org/SDL/rev/91f56dcad879
This fix applies SDL_TOUCH_MOUSEID to 'mouse' events coming from touch devices,
but only when relative-mouse-mode is turned OFF. This bug is still present
when relative-mouse-mode is ON, however Microsoft does not provide documentation
on whether or not those input events (which come from WM_INPUT) can be
identified as touch-specific or not. Unofficially, that data might be available
(via GetMessageExtraInfo()), however this patch only uses MS-documented APIs.
This change does a few things, all with regards to the WinRT implementation of
SDL_GetPrefPath():
1. it fixes a bug whereby SDL_GetPrefPath() did not create the directory it
returned. On other SDL platforms, SDL_GetPrefPath() will create separate
directories for its 'org' and 'app' folders. Without this, attempts to create
files in the pref-path would fail, unless those directories were first created
by the app, or by some other library the app used. This change makes sure
that these directories get created, before SDL_GetPrefPath() returns to its
caller(s).
2. it defaults to having SDL_GetPrefPath() return a WinRT 'Local' folder
on all platforms. Previously, for Windows Store apps, it would have used a
different, 'Roaming' folder. Files in Roaming folders can be automatically,
and synchronized across multiple devices by Windows. This synchronization can
happen while the app runs, with new files being copied into a running app's
pref-path. Unless an app is specifically designed to handle this scenario,
there is a chance that save-data could be overwritten in unwanted or
unexpected ways.
The default is now to use a Local folder, which does not get synchronized, and
which is arguably a bit safer to use. Apps that wish to use Roaming folders
can do so by setting SDL_HINT_WINRT_PREF_PATH_ROOT to "roaming", however it
is recommended that one first read Microsoft's documentation for Roaming
files, a link to which is provided in README-winrt.md.
To preserve older pref-path selection behavior (found in SDL 2.0.3, as well as
many pre-2.0.4 versions of SDL from hg.libsdl.org), which uses a Roaming path
in Windows Store apps, and a Local path in Windows Phone, set
SDL_HINT_WINRT_PREF_PATH_ROOT to "old".
Please note that Roaming paths are not supported on Windows Phone 8.0, due to
limitations in the OS itself. Attempts to use this will fail.
(Windows Phone 8.1 does not have this limitation, however.)
3. It makes SDL_GetPrefPath(), when on Windows Phone 8.0, and when
SDL_HINT_WINRT_PREF_PATH_ROOT is set to "roaming", return NULL, rather than
silently defaulting to a Local path (then switching to a Roaming path if and
when the user upgraded to Windows Phone 8.1).
WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
Visual C++ 2013 Update 4 re-introduced the Sleep() function to WinRT apps (for
code that targets Windows 8.1 and Windows Phone 8.1). This led to a build
error, as SDL was defining it's own Sleep() function (to make up for the lack
of a public Sleep() function). The fix makes sure that SDL's custom Sleep()
function is only used when Windows' Sleep() is not available.
Many thanks go out to Sergiu Marian Gaina for the fix!
Only the first-pressed finger wpuld get reported as having moved (via SDL's
touch APIs). Subsequently pressed fingers wouldn't report as being moved, even
though the OS was reporting (to SDL) that they had moved.
David Ludwig