-Wundef errors from clang-11.1 when targeting macOS
Targeting i386 against 10.8 SDK:
In file included from src/SDL_assert.c:21:
In file included from src/./SDL_internal.h:52:
In file included from include/SDL_config.h:33:
include/SDL_platform.h:73:5: error: 'TARGET_OS_TV' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
^
1 error generated.
src/joystick/iphoneos/SDL_mfijoystick.m:38:5: error: 'TARGET_OS_IOS' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
^
src/joystick/iphoneos/SDL_mfijoystick.m:460:5: error: 'TARGET_OS_TV' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
^
2 errors generated.
src/filesystem/cocoa/SDL_sysfilesystem.m:83:6: error: 'TARGET_OS_TV' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
^
1 error generated.
Targeting x86_64 against 10.12 SDK:
src/video/SDL_video.c:1492:25: error: 'TARGET_OS_MACCATALYST' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
^
1 error generated.
To enter Bluetooth pairing mode hold B and Action (button with circle) buttons for 3 seconds.
It works via usual HIDAPI if special filter driver is not installed:
https://www.amazon.com/gp/help/customer/display.html?nodeId=GZCT4CTFHXLHEB9T
With that driver installed it mimics Xbox One controller and works via XInput under Windows.
Under DInput this controller is not usable at all.
In a more ideal world, we'd use the appropriate `__attribute__` here, but
it's one thing in a public header that probably shouldn't be there at all, so
this is good enough for now.
Fixes#4307.
If you hide a window on Mutter, for example, the compositor never requests
new frames, which will cause Mesa to block forever in eglSwapBuffers to
satisfy the swap interval.
We now always set the swap interval to 0 and manage this ourselves, handing
the frame to Wayland when it requests a new one, and timing out at 10fps just
to keep apps moving if the compositor wants no frames at all.
My understanding is that other protocols are coming that might improve upon
this solution, but for now it solves the total hang.
Fixes#4335.
commit 6b8f933589aa3925978a23e77a305a7e89c6ae4a
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:31:29 2021 +0800
update the dynapi by `gendynapi.pl`
commit ebd1790c19983b652713f40ab1e139e485e1a2b7
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:17:48 2021 +0800
revert the change in src/dynapi
commit 734b5f85c1613070081e39238e84198128971b53
Merge: 5a56e5a8 5ac6bd54
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:14:40 2021 +0800
Merge remote-tracking branch 'libsdl/main' into jixingcn
commit 5a56e5a8227d9cff6b497b681c618a76bec1cae1
Author: Xing Ji <jixingcn@gmail.com>
Date: Mon Mar 22 23:55:10 2021 +0800
Fix#3596, can call the `SDL_TLSCleanup` to cleanup the TLS data when closing the application
The llvm-mingw project includes cross-compilers targeting ARM: https://github.com/mstorsjo/llvm-mingw/releases
Currently, compilation fails with this configuration, because neon features are used as long as __ARM_NEON is defined, but arm_neon.h was not included.
This should not change anything at all within the compiled library, but it does make the header file easier to read for non-C programmers who don't expect an octal value.
In some cases, it can be useful to have the KMSDRM backend even if it cannot
be used for rendering. An app may want to use SDL for input processing while
using another rendering API (such as an MMAL overlay on Raspberry Pi) or
using its own code to render to DRM overlays that SDL doesn't support.
This also moves the check for DRM master to an earlier point where we can fail
initialization of the backend, rather than allowing the backend to initialize
then failing the creation of a window later.
SDL has been missing a bunch of these 'isX' functions for some time,
where X is some characteristic of a given character.
This commit adds the rest of them to the SDL stdlib, so now we have:
- SDL_isalpha()
- SDL_isalnum()
- SDL_isblank()
- SDL_iscntrl()
- SDL_isxdigit()
- SDL_ispunct()
- SDL_isprint()
- SDL_isgraph()
The DJGPP compiler emits many warnings for conflicts between print
format specifiers and argument types. To fix the warnings, I added
`SDL_PRIx32` macros for use with `Sint32` and `Uint32` types. The macros
alias those found in <inttypes.h> or fallback to a reasonable default.
As an alternative, print arguments could be cast to plain old integers.
I opted slightly for the current solution as it felt more technically correct,
despite making the format strings more verbose.
vladius
In SDL_cpuinfo.h it seems like <intrin.h> is not included when __clang__ is defined, as the comment in the file explicitly reads:
"Many of the intrinsics SDL uses are not implemented by clang with Visual Studio"
However, the SDL_endian.h header does include <intrin.h> without any precautions like:
>#ifdef _MSC_VER
>#include <intrin.h>
>#endif
Maybe it should be changed to something like:
>#ifdef _MSC_VER
>#ifndef __clang__
>#include <intrin.h>
>#endif
>#endif
By default, we will minimize the window when we receive Alt+Tab with a
full-screen keyboard grabbed window to allow the user to escape the
full-screen application.
Some applications like remote desktop clients may want to handle Alt+Tab
themselves, so provide an opt-out via SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED=0.
This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(),
SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new
SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise
this functionality and makes a minor fix to X11 that I missed in
https://hg.libsdl.org/SDL/rev/02a2d609369b
To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to
SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards
compatibility with older code.
jibb
New hint to let the user opt out of having Switch controllers' Home button lit when opened.
This is more consistent with the Switch itself (which doesn't light the button normally) and may be preferred by users who may disconnect their controller without letting the application close it.
I think this warrants a Switch-specific hint because the default behaviour is unusual (inconsistent with using a Switch controller on a Switch itself or with some other programs on PC), and because of that it's distinct from other lights (the player number on Switch controllers and the player colour on PlayStation controllers).