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.
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.
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.
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.
This lets you build a custom embedded device that roughly offers the "this
process is going to the background NOW" semantics of SDL on a mobile device.
orbea
I am having a parallel build problem with -j3 or higher using the autotools build and slibtool instead of GNU libtool. Basically slibtool is faster than GNU libtool and it will start working before mkdir starts or finishes creating the build/ directory.
From Tom Black:
I'm having problems initializing the sensor module. I'm compiling with a standard ./configure && make && sudo make install, and the module says it's enabled, but SDL_Init(SDL_INIT_EVERYTHING) is failing with SDL_GetError() returning "SDL not built with sensor support".
add HAVE_ENDPOINTVOLUME_H, HAVE_MMDEVICEAPI_H and HAVE_AUDIOCLIENT_H
in SDL_config.h.in, SDL_config.h.cmake, SDL_config_windows.h, and in
SDL_config_winrt.h.
Now you don't need the latest Wayland installed to build with
newer protocols supported, as they'll build correctly; even if
your system can't use them, we can make intelligent decisions
at runtime about what's available on the current machine anyhow.
This also simplifies some logic and possible failure cases in
the configure and CMake scripts.
Fixes Bugzilla #4207.
This is just in parity with the existing zxdg-shell-unstable-v6 code. Making
the Wayland target robust (and uh, with title bars) is going to take a lot
of work on top of this.
Zack Middleton
Running top-level SDL configure on macOS 10.11 resulted in the errors below because automake removed the brackets about the tests.
./configure: line 15756: : command not found
./configure: line 15759: -Iinclude -I/Users/zack/SDL/include -idirafter /Users/zack/SDL/src/video/khronos : No such file or directory
./configure: line 15763: : command not found
Azamat H. Hackimov
When you try use SDL2 2.0.8 in CMake project in Linux, it complains about trailing spaces in sdl2.pc:
CMake Error at CMakeLists.txt:147 (add_executable):
Target "TestSimpleMain" links to item "-L/usr/lib64 -lSDL2 " which has
leading or trailing whitespace. This is now an error according to policy
CMP0004.
Ozkan Sezer
Configury adds Metal.framework to linkage even if it is not available.
My solution is setting enable_render_metal to no when Metal.framework
is not found
This is meant to be the desktop-enhanced version of wl_shell. Right now we
just match what the existing wl_shell code does, but there are other areas of
functionality available to us now, that we can fill in later.
This uses the "unstable" API, since this is what ships in Ubuntu 17.10 (as
part of Wayland 1.10), but Wayland 1.12 promotes this to stable with extremely
minor changes. We will add support for the stable version when it makes sense
to do so.
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.
Simon Hug
When RWops seeks with fseek or fseeko it uses the types long or off_t which can be 32 bits on some platforms. stdio_seek does not check if the 64-bit integer for the offset fits into a 32-bit integer. Offsets equal or larger than 2 GiB will have implementation-defined behavior and failure states would be very confusing to debug.
The attached patch adds range checking by using the macros from limits.h for long type and some bit shifting for off_t because POSIX couldn't be bothered to specify min and max macros.
It also defines HAVE_FSEEKI64 in SDL_config_windows.h so that the Windows function gets picked up automatically with the default config.
And there's an additional error message for when ftell fails.
Andreas Falkenhahn
When compiling SDL for the Raspberry Pi, I have to use the --host parameter to enable compilation of the native Raspberry Pi video driver, like so:
--host=arm-raspberry-linux-gnueabihf
It took me a while to figure out that this was necessary in order to have the native Raspberry Pi video driver compiled in. I think it would be better if there was an option like --enable-video-rpi that could be passed to configure and that would also show up when saying configure --help. Currently, it?s rather difficult to figure out that you have to use the --host parameter with arm-raspberry-linux-gnueabihf in order to get Raspberry Pi video support. It?s also somewhat inconsistent because most other video drivers can in fact be enabled/disabled through specific configure parameters but there is no such parameter for the native Raspberry Pi video driver.
Ozkan Sezer
Cmake checks for float.h, but configure does not: the attached patch
adds float.h to checked headers in configury, and it adds the missing
HAVE_FLOAT_H macro to SDL_config.h.cmake and SDL_config.h.in.
In SDL_config_macosx.h and SDL_config_windows.h, defined HAVE_FLOAT_H
as 1, where I know that it's true.
Colin Barrett
Using the pre-built x86 devel libs from here:
https://www.libsdl.org/release/SDL2-devel-2.0.5-VC.zip
If I have:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);
and I'm using ANGLE/(a GL driver that doesn't provide an ES2 context) such that SDL_EGL_CreateContext is called by SDL_GL_CreateContext, I get the error "Could not create EGL context (context attributes are not supported)" and no context is created.
Looking at the code in SDL_EGL_CreateContext - if gl_config.flags is non-zero, it looks like the code in the section guarded with "#ifdef EGL_KHR_create_context" should be executed - but it apparently isn't.
Is it possible this section hasn't been compiled into the pre-built libraries? If I build SDL2.dll myself using the Visual C++ solution (VS2015 Community Update 3) then the call succeeds as I expect
Tom Seddon
0f0ad62237 (git head at the time of writing); Visual Studio 2015, toolset v140, Platform 10.0.14393.0, building for x64
Windows non-MinGW cmake build sets defines implying wcslcpy and wcslcat are available, but Windows doesn't have these functions.
Ryan C. Gordon
That's weird, these are the exact two functions that Emscripten incorrectly believed it had until we upgraded the buildbot's emsdk install.
Not sure what's up with this, but it's possibly not a MingW-specific thing!
macOS currently needs this if you build with X11 support. iOS doesn't
(currently), but it doesn't hurt to compile it in case we do something
Unixy on that platform later on.
manuel.montezelo
Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015
--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--------------------------------------------------------
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
Jonas Kulla
This eliminates the need to manually compile in SDL_main_android.c.
Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking.
I don't know how the nkd-build process works, but unless it was
for some reason linking libSDL2main.a it should be unaffected.
Rafal Muzylo
"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)
Juha Niemim?
On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/7213ae46e870 ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Sam Lantinga
Simon McVittie
Ryan C. Gordon
Ozkan Sezer
Cameron Cawley
Manuel Alfayate Corchete
James Le Cuirot
David Ludwig
Anuj Mittal
Ethan Lee
Alex Szpakowski
Guillermo A. Amaral
Brandon Schaefer
Philipp Wiesemann