Cameron Cawley
stdlib: Added SDL_round, SDL_roundf, SDL_lround and SDL_lroundf
The default implementation is based on the one used in the Windows RT video driver.
Substring
I was trying the KMSDRM video backend with some very simple programs that were working ok on 2.0.12. The same code won?t work on the current dev branch and I get:
DEBUG: check_modesetting: probing ?/dev/dri/card0?
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: check_modesetting: probing ?/dev/dri/card0?
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: KMSDRM_VideoInit()
DEBUG: Opening device /dev/dri/card0
DEBUG: Opened DRM FD (3)
DEBUG: no atomic modesetting support.
DEBUG: Video subsystem has not been initialized
INFO: Using SDL video driver: (null)
DEBUG: Video subsystem has not been initialized
After carefully checking, the radeon driver doesn?t support atomic modesetting. That?s not the only problem : the same happens with the amdgpu driver if we disable Display Core (kernel parameter amdgpu.dc=0, which is required to get analogue outputs working).
This is a major regression in the KMSDRM driver.
Using atomic mode setting is great, but having no fallback to the "standard KMS" is bad.
configure output is practically unchanged. there are still lots of
AC_TRY_COMPILE/AC_TRY_LINK replacements needed to really eliminate
the warnings, but that's for another time.
Alex S
Evdev headers aren't actually included in the base system (well, it has a private copy), they are available through the devel/evdev-proto port instead. We also have devel/libinotify and devel/libudev-devd shims, I didn't verify whether they work with SDL.
In recent versions of EGL headers on Linux, the MESA_EGL_NO_X11_HEADERS macro is
deprecated and has been replaced with EGL_NO_X11. As a result, the configure
script would fail the compilation check for EGL headers and disable EGL (and by
extension, Wayland) support when X11 headers are not installed. Fix this by
adding the correct macro to disable X11 support in the headers.
wahil1976
This patch adds the KBIO text input driver for FreeBSD, which allows text input to fully work without text spilling out into the console. It also supports accented input, AltGr keys and Alt Lock combinations.
Tested with US accent keys layout and various AltGr layouts.
Alex S
...which allows SDL to talk to webcamd/iichid. (Webcamd actually bundles quite a few gamepad drivers.) Note that this does _not_ disable usbhid, both joystick backends will be compiled.
This works on capability bitfields that can either come from udev or
from ioctls, so it is equally applicable to both udev and non-udev
input device detection.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows one to build Raspberry Pi versions on an ancient version of
Raspbian and get both the KMSDRM and RPI video targets built into SDL, giving
maximum binary compatibility from linking against an older glibc, etc, but
also making one library that can access video on all RPi models and OS
releases.
- SDL_config.h.in: add missing defines SDL_SENSOR_COREMOTION
and SDL_SENSOR_WINDOWS (configure did set SDL_SENSOR_WINDOWS
but it never went in SDL_config.h or Makefile.)
- SDL_config.h.cmake: remove duplicated SDL_SENSOR_XXX cmake
defines.
- autofoo, cmake: check for sensorsapi.h header before enabling
windows sensors.
jackmacwindowslinux
I'm testing my application that uses SDL2 on the new Apple Silicon Macs. I set up the SDL 2.0.12 source code from the website and tried to build it. The first issue I ran into was that it was always building OpenGL ES, even if --disable-video-opengles was passed to configure. OpenGL ES headers do not seem to be present on the Apple Silicon macOS SDK, except for the iOS SDK headers. Then I had problems with the joystick driver, where some classes used on iOS were not available on macOS.
After looking through the configure.ac script a bit, I found that iOS targets are selected when the build host matches "arm*-apple-darwin*". Clang on macOS 11.0 on arm64 reports the host as "arm64-apple-darwin20.0.0", which matches the iOS target. This means that ARM Mac compilation will always be detected as iOS. Unfortunately, there doesn't seem to be an easy way to detect Mac vs. iOS targets, since they now both use the same triplet & compiler for building.
I'm not sure what the best way to fix this is, but maybe there could be an additional target flag to specify whether to build for macOS or iOS? This might break compatibility, though: with this approach, either all old scripts that used configure to build for iOS fail, or all new builds on macOS without a flag fail (silently?).
The compiler understands it, but the "qcc" compiler driver doesn't, and the
standard Khronos headers upset QNX anyhow, since they try to include X11
headers in the __unix__ section.
If this is a problem, we can write a test for the compiler flag, but shouldn't
we _always_ use our Khronos headers instead of depending on the system...?
wengxt
Due to the new major fcitx version is coming close, the existing code need to be ported to use new Fcitx dbus interface.
The new dbus interface is supported by both fcitx 4 and 5, and has a good side effect, which is that it will work with flatpak for free. Also the patch remove the dependency on fcitx header. Instead, it just hardcodes a few enum value in the code so need to handle the different header for fcitx4 or 5.
A project being built entirely statically will call pkg-config with
--static, which utilises the Libs.private field. Conversely it will
not use --static when not being built entirely statically, even if
there is only a static build of SDL available. This will most likely
cause the build to fail due to underlinking unless we merge the Libs
fields.
This is what the Meson build system does when it generates pkg-config
files. This also also follows the behaviour of sdl2-config.
At the same time, the runtime linker flags are not applicable to
static-only builds so only add them for shared builds.
Apparently, recent versions of autotools will issue an error if an empty
description is supplied to AC_DEFINE(). Avoid these errors by just
adding a space in the square brackets.
Partially fixes Bugzilla #4908.
Jimb Esser
Add new RawInput controller API, and improved correlation with XInput/WGI
Reorder joystick init so drivers can ask the others if they handle a device reliably
Do not poll disconnected XInput devices (major perf issue)
Fix various cases where incorrect correlation could happen
Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation
Correlate by axis motion as well as button presses
Fix failing to zero other trigger
Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init()
Add missing device to device names
Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices
Updated to SDL 2.0.13 code with the following notes:
New HID driver: xbox360w - no idea what that is, hopefully urelated
SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data.
SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem.
Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason.
Something changed in how devices get names, so getting generic names.
Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
This fixes compilation errors that occur when trying to compile SDL2 for
a X11-less target. The errors were due to the fact that Mesa will
include X11 headers unless a couple of macros are defined.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Christoph Charles
The new source files for coremotion sensors don't seem to have been included correctly in configure.in. This leads to the build script ios-build.sh to fail at link time, complaining about missing symbols, namely about missing SDL_COREMOTION_SensorDriver.
Fixes a race where we try to build version res file in build directory
before it has even been created. Prevents errors like:
/bin/bash ../SDL2-2.0.10/build-scripts/updaterev.sh
/bin/bash ../SDL2-2.0.10/build-scripts/mkinstalldirs build
mkdir -p -- build
x86_64-pokysdk-mingw32-windres --include-dir=/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/x86_64-nativesdk-mingw32-pokysdk-mingw32/nativesdk-libsdl2/2.0.10-r0/recipe-sysroot/opt/poky/3.0/sysroots/x86_64-pokysdk-mingw32/usr/include ../SDL2-2.0.10/src/main/windows/version.rc build/version.o
x86_64-pokysdk-mingw32-windres: build/version.o: No such file or directory
Makefile:692: recipe for target 'build/version.o' failed
make: *** [build/version.o] Error 1
make: *** Waiting for unfinished jobs....
touch build/.created
WARNING: exit code 1 from a shell command.
Extension of fix:
https://hg.libsdl.org/SDL/rev/bb65ba8e039b
Signed-off-by: Anuj Mittal <am.devel@gmail.com>
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Callum McGing
While the CMake build checks for ibus and does enable the ibus backend with set(HAVE_IBUS_IBUS_H TRUE), this does not define SDL_USE_IME, thus CMake built SDL2 (as in Arch Linux) cannot use IME at all.
The attached patch fixes this behaviour when building against ibus. IME support will still fail when only fcitx is available on the build system.
This is currently supported on Linux and macOS. iOS and Android are not
supported at all, Windows support could be added with some changes to the libusb
backend. The Visual Studio and Xcode projects do not use this feature.
Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.
(and it defaults to "yes" on those platforms. Other places, which use libusb,
still default to no because they probably need root permissions to work.)
Ozkan Sezer
A horde of strict aliasing violation warnings are emitted from joystick
layer, and also from a few other places. This happens with gcc-4.4.7 on
Linux CentOS 6.10. Some other sysjoystick would possibly have the same
warnings.
Attached my full log here. Example entry:
src/joystick/SDL_joystick.c: In function 'SDL_GetJoystickGUIDInfo':
src/joystick/SDL_joystick.c:1094: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
Jan Martin Mikkelsen
The evdev interface is available on FreeBSD, with the xf86-input-evdev for include files in /usr/local/include/linux, so <linux/input.h> works, or when build with the native evdev option, where <dev/evdev/input.h> is available.
Sam Lantinga
Manuel Alfayate Corchete
Ozkan Sezer
Ryan C. Gordon
Brian Kubisiak
Simon McVittie
Cameron Cawley
James Le Cuirot
Paul Cercueil
Jimb Esser
David Ludwig
Anuj Mittal
Ben Avison
Ethan Lee
Alex Szpakowski
Hugh McMaster