C.W. Betts
This patch adds support to the GameController framework on macOS Big Sur and later, adding support for MFi controllers as well as rumble support for PS4 and Xbox One. There is some code to make sure that the IOKit joystick handler doesn't include two controllers at once.
While the GameController framework is present in earlier versions of macOS, there was no public, approved way of checking if a specific IOHIDDevice is a controller that GameController could handle. This was changed in Big Sur.
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Docs:
http://git.0pointer.net/rtkit.git/tree/README
CLIENTS:
To be able to make use of realtime scheduling clients may
request so with a small D-Bus interface that is accessible on
the interface org.freedesktop.RealtimeKit1 as object
/org/freedesktop/RealtimeKit1 on the service
org.freedesktop.RealtimeKit1:
void MakeThreadRealtime(u64 thread_id, u32 priority);
void MakeThreadHighPriority(u64 thread_id, s32 priority);
The SDL_USE_LIBDBUS define is set inside SDL_debug.h, therefore the
circular dependency made it impossible for this feature to be enabled.
Instead, guard SDL_dbus.h based on the autoconf variable HAVE_DBUS_DBUS_H
Additionally, fix one of the rtkit comments. CAP_SYS_NICE isn't required
to achieve high priority. But there is some scheduler config that rtkit
needs the app to setup.
It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.
maxxus
The Dualshock 3's motion sensors don't seem to be reported by the call to EVIOCGBIT but they still send EV_ABS events. Because they're not reported by EVIOCGBIT they're not assigned a proper axis ids and the default of 0 is used, which is the valid id for the left analog sticks left/right axis.
Dominik Reichardt
Xcode warns about
"Traditional headermap style is no longer supported; please migrate to using separate headermaps and set 'ALWAYS_SEARCH_USER_PATHS' to NO."
Just doing the latter is enough to silence the warning without ill effects on compiling. This affects the macOS Xcode projects as well as the iOS projects. Definitely not a bug but an annoying warning that could go away.
C.W. Betts
This cleans up the Xcode project by setting the Xcode groups to the corresponding directories. This also removes the Resources folder in OS X's Products group and adds the CoreBluetooth framework to the iOS tests (this is needed due to the addition of hidapi.
Eric Wasylishen
The following patch adds Metal.framework to the "link binary with libraries" section of each test program, with "status" set to "optional", which fixes link errors on all of the test programs. I'm not sure if this is a correct fix - the fact that this was necessary might indicate the static SDL2.a library has a hard dependency on Metal.framework (?) - but it gets the test programs working in Xcode again.
It also adds testyuv_cvt.c to the testoverlay2 target, fixing a link error.
Andrey
Seems latest google angle library successfully built & tested under macOS'es.
https://github.com/google/angle
We need to use GLES2 to implement true cross-platform code.
New functions get and set the YUV colorspace conversion mode:
SDL_SetYUVConversionMode()
SDL_GetYUVConversionMode()
SDL_GetYUVConversionModeForResolution()
SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats.
Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.
Mark Callow
Xcode 9 emits a warning to validate project settings. The changes it proposes are
1. [iOS] Update the iOS deployment target to 8.0 since Xcode does
not support anything older.
2. [macOS] Target 'Framework' - Automatically Select Archectures.
3. [iOS & macOS] Turns on a bunch more compile warnings, a *lot* more on iOS.
4. [iOS & macOS] Turn on "Missing Localizability".
I want to confirm if it is ok to accept these changes and submit updated project files.
Since Alex Szpakowski has just removed iOS 7 guard ifdef's, I'm guessing 1 isn't a problem.
2 is probably ok for anyone building themselves. I wonder if it may cause problems for building distribution binaries.
3 shouldn't be a problem either provided any newly emitted warnings are fixed.
4 I am unfamiliar with. The description says "This will turn on the static analyzer to check for "Missing Localizability", because this project is localized for multiple languages." I suppose this may cause new warnings.
Sam Lantinga
Ozkan Sezer
Ryan C. Gordon
David Ludwig
Alex Szpakowski