Mon, 23 Mar 2020 14:54:31 -0400iOS: fixed bug whereby some SDL testing apps weren't launching
David Ludwig <dludwig@pobox.com> [Mon, 23 Mar 2020 14:54:31 -0400] rev 13668
iOS: fixed bug whereby some SDL testing apps weren't launching

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).

Sun, 22 Mar 2020 20:09:14 -0400Do not overwrite window surface created by driver
Jay Petacat <jay@jayschwa.net> [Sun, 22 Mar 2020 20:09:14 -0400] rev 13667
Do not overwrite window surface created by driver

If a driver's implementation of CreateWindowFramebuffer sets the window
surface, use that rather than overwriting it. A driver may set the window
surface if data cannot be passed via the CreateWindowFramebuffer output
parameters (e.g. surface palette colors).

Mon, 23 Mar 2020 11:42:44 -0700Fixed building back to Mac OSX using the 10.7 SDK
Sam Lantinga <slouken@libsdl.org> [Mon, 23 Mar 2020 11:42:44 -0700] rev 13666
Fixed building back to Mac OSX using the 10.7 SDK

Sun, 22 Mar 2020 22:03:38 -0400alsa: Fix excessive I/O causing higher CPU usage SDL-1.2
Ryan C. Gordon <icculus@icculus.org> [Sun, 22 Mar 2020 22:03:38 -0400] rev 13665
alsa: Fix excessive I/O causing higher CPU usage

"On GCW Zero jz4770 platform, I saw higher than usual CPU usage when
running a more recent kernel (4.xx series versus 3.xx). Upon
investigation, it was found that the ALSA pcm file was not blocking
as it should. This resulted in ~30-50,000 system calls a second that
were unnecesary.

After adjusting the order in which SDL requests its pcm blocking mode,
the number of syscalls a second has dropped to a much smaller figure,
< 1,000/sec if I recall correctly. CPU usage also dropped by ~5%."

(This patch was written by Daniel Silsby.)

Fixes Bugzilla #4941.

Sun, 22 Mar 2020 14:32:47 -0400opengl: Don't enable/disable texturing except when actually rendering.
Ryan C. Gordon <icculus@icculus.org> [Sun, 22 Mar 2020 14:32:47 -0400] rev 13664
opengl: Don't enable/disable texturing except when actually rendering.

Otherwise our cached state goes out of sync when updating a texture. Since
these state changes aren't necessary, they were removed instead of updating
the cached state.

Fixes Bugzilla #4998.

Sun, 22 Mar 2020 11:01:14 -0700Fixed bug 5051 - Switch Pro Controller hidapi driver does not report battery levels when connected via Bluetooth
Sam Lantinga <slouken@libsdl.org> [Sun, 22 Mar 2020 11:01:14 -0700] rev 13663
Fixed bug 5051 - Switch Pro Controller hidapi driver does not report battery levels when connected via Bluetooth

bluenaxela+sdl

I've noticed that the Switch Pro Controller hidapi driver does not report battery levels when connected via Bluetooth, despite having code for setting joystick->epowerlevel.

This is caused by the driver always using k_eSwitchInputReportIDs_SimpleControllerState via Bluetooth. Using that mode means that the state reports you get back from the controller do not include battery state. Not using the full controller state over Bluetooth effectively makes this driver's support for setting joystick->epowerlevel entirely pointless, only ever reporting SDL_JOYSTICK_POWER_WIRED.

Is there a reason this was set to only use SimpleControllerState via Bluetooth?

I've attached a patch I'm using to allow getting battery level for the Switch Pro Controller.

A couple notes about this patch:
1) It changes LoadStickCalibration to accept the input_mode that is selected, because that's really what should determine what is used for stick extents, since stick extents differ between the modes.
2) In my patch I only use FullControllerState when the vid/pid matches the official Switch Pro Controller, as a cautionary measure in case some third-party controllers have problems with FullControllerState mode via Bluetooth (I noticed a HORI Wireless Switch Pad I had seemed to not read controller calibration correctly for stick extents. Maybe it's calibration data was uninitialized on account of having never been used with a Switch? I'm unsure, though if that guess is right maybe SDL2 should be detecting an uninitiated calibration state and using some sensible defaults)

Fri, 20 Mar 2020 21:05:07 -0700Allow Valve devices in driver check, we know they're well behaved controllers
Sam Lantinga <slouken@libsdl.org> [Fri, 20 Mar 2020 21:05:07 -0700] rev 13662
Allow Valve devices in driver check, we know they're well behaved controllers

Fri, 20 Mar 2020 20:53:26 -0700Removed blacklist entries for devices that aren't game controllers, allow Steam Controllers
Sam Lantinga <slouken@libsdl.org> [Fri, 20 Mar 2020 20:53:26 -0700] rev 13661
Removed blacklist entries for devices that aren't game controllers, allow Steam Controllers

Fri, 20 Mar 2020 13:44:50 -0700Only enumerate HID devices on Windows that have gamepad HID usages
Cameron Gutman <aicommander@gmail.com> [Fri, 20 Mar 2020 13:44:50 -0700] rev 13660
Only enumerate HID devices on Windows that have gamepad HID usages

There are a number of poorly behaved HID devices that time out on attempts to
read various strings. Rather than end up on an endless treadmill of blacklisting
broken devices, reduce our risk by only querying devices that are gamepads.
SDL_hidapijoystick.c already checks these same usages, so we shouldn't
exclude any working HID devices (caveat below).

This also makes HidP_GetPreparsedData() and HidP_GetCaps() failure skip
the device entirely, but that seems desired. If a device can't even return basic
top-level collection data properly, we want nothing to do with that broken device.
If we do find devices that work with HIDAPI joystick and fail these calls, we can
add an exception via VID+PID matching.

Fri, 20 Mar 2020 20:45:30 -0700Fixed bug 5049 - HORI Wireless Switch Pad does not connect properly via Bluetooth
Sam Lantinga <slouken@libsdl.org> [Fri, 20 Mar 2020 20:45:30 -0700] rev 13659
Fixed bug 5049 - HORI Wireless Switch Pad does not connect properly via Bluetooth

bluenaxela+sdl

The HORI Wireless Switch Pad does not properly connect via bluetooth. I did some debugging and found that the code that tries to control the Home LED causes this controller to disconnect.