The wrong logic, copy/pasted to a bunch of places, would correctly disable
the dynamic loading but fail to specify the libraries that SDL would now need
to explicitly link against.
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
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.
Sven-Hendrik Haase
In CMake I currently have trouble activating hidapi support as libusb-1.0 isn't ever correctly detected as it's searched for by the wrong name.
configure.ac correctly does this:
PKG_CHECK_MODULES([LIBUSB], [libusb-1.0], have_libusb=yes, have_libusb=no)
However, sdlchecks.cmake does this:
pkg_check_modules(LIBUSB libusb)
but it needs to be:
pkg_check_modules(LIBUSB libusb-1.0)
Eric Jing
When the project directory path contains spaces, CMake butchers the include path for the hidapi files.
I traced the problem to the cmake/sdlchecks.cmake file at line 1091, which sets flags for the build process. I surrounded the problem flag with double quotes, shown below, and CMake works with spaces in the project directory path.
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.
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.
Fixes CMake not being able to find X11 on FreeBSD (which generally has the
headers in /usr/local/include/X11).
List of other popular places borrowed from CMake's FindX11 module.
This worked on the configure script because of magic in the AC_PATH_X macro.
Fixes Bugzilla #4815.
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.
Martin Gerhardy
- list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CLFAGS} ${XKB_CLFLAGS})
+ list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CFLAGS} ${XKB_CFLAGS})
CFLAGS is spelled wrong in two different ways for EGL and XKB
And while you are on it...
sdl needs mir >= 0.24 afaik - it fails on travis-ci (ubuntu 14.04 LTS with 0.18 installed and in other environments, too (e.g. https://github.com/urho3d/Urho3D/issues/1685)
To fix this one should add a min version check to pkg_check_modules like this
- pkg_check_modules(MIR_TOOLKIT mirclient mircommon)
+ pkg_check_modules(MIR_TOOLKIT mirclient>=0.24 mircommon)
-Enabling checking for GCC_ATOMICS also on clang by default. This way all Android ABIs build successfully
-Android cmake: Threading was not enabled correctly
-Android cmake: Timers and dynamic lib loading were not included in the sources
Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
Juha Niemim?ki
Fix for PTHREAD_MUTEX_RECURSIVE_NP check and restoring the original flags
Two fixes proposed:
1) Looks like there is a copy-paste issue regarding PTHREAD_MUTEX_RECURSIVE_NP check.
2) Compiler flag restoration doesn't look symmetrical regarding if/endif blocks. Moved to an outer block (if PTHREADS).