It didn't work at all because shared libs defined in CMake with
add_library() need something like IMPORTED_IMPLIB (pointing to a .dll.a
or .lib for th DLLs) set to link on Windows.
But even with that it didn't work because the order of the libs is very
important: it must be -lmingw32 -lSDL2main -lSDL -mwindows - but
with normal add_library(SDL2::SDL2 SHARED IMPORTED) libs, SDL2 itself
is always linked first.
So I use an "INTERFACE" library (usually used for header-only libs), which
doesn't implicitly/automatically link anything so I can specify the whole
order of the linked libs.
(SDL2::SDL2-static is completely untested)
this makes it easier to create a portable sdl2-config.cmake that doesn't
hardcode its path (by replacing the hardcoded prefix with something
like "${CMAKE_CURRENT_LIST_DIR}/../../..")
When hint SDL_HINT_OPENGL_ES_DRIVER is set to "1" (e.g. for ANGLE support), assertion due to !_this->gl_config.driver_loaded can be causes while EGL is available.
When relative mode is enabled and not using warp mode, the cursor is
being clipped to the window. Therefore there is no reason to restore the
cursor position to the center.
Avoiding the warp to center simplifies mouse position event flow, as we
are no longer potentially receiving mouse events for the automated
movement of the cursor and can be (mostly) assured that an incoming
event from the windowing system is that of external means.
The implementation of clip logic for relative mode seemed to
unnecessarily limit the usable area to the middle of the window, in a
2x2 pixel region. This has the adverse side effect of moving the
operating system cursor to that location, even if it is in a valid
location in the window.
While in most scenarios this is handled correctly (by storing the
original position of the cursor in the window and restoring when leaving
relative mode), there are edge cases where this clip operation can cause
WM_MOUSEMOVE to fire at a point in time where it counts as a relative
delta from SDL's perspective.
-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.
X11_SetDisplayMode currently calls X11_XRRSetCrtcConfig alone. This results
in the monitor's viewport getting changed, but the underlying screen dimensions
stay the same.
The spec indicates that RRSetCrtcConfig only changes the crtc mode and has no effect
on the screen dimensions, only mentioning that the new crtc must fit entirely within the
screen size. For the size to change, RRSetScreenSize also needs to be called.
This affects Metro Exodus on Linux, when changing the resolution in the in-game settings
Metro gets stuck in a loop waiting for the size of its vulkan surface to change. Because
XRRSetScreenSize is not called the screen size is never changed, the vulkan surface dimensions
do not change, and Metro hangs forever watching for a surface size update that will
never come.
This change disables the CRTC, calls XRRSetScreenSize, and then updates the
CRTC configuration. This fixes changing the resolution from the Metro settings.
Tested with:
Metro Exodus, Portal 2
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.
AC_CHECK_HEADER() emits warnings when configuring for non-x86, because
the preprocessor check is OK but the compile check is not:
configure: WARNING: immintrin.h: present but cannot be compiled
configure: WARNING: immintrin.h: check for missing prerequisite headers?
configure: WARNING: immintrin.h: see the Autoconf documentation
configure: WARNING: immintrin.h: section "Present But Cannot Be Compiled"
configure: WARNING: immintrin.h: proceeding with the compiler's result
It is called from WGI before the normal joystick detection has been run, so it needs to actually enumerate currently connected devices.
We can skip the logic checking for other drivers also supporting this device, because that logic is duplicated from the call site.
