Depending on the underlying EGL library, it may be desirable to
conditionally set some specific EGL attributes depending on available
extensions and other application state.
SDL's EGL usage makes this a little bit complicated because:
- there are multiple functions used to set up a working EGL context
- some of these functions take different types of EGL attributes
(EGLAttrib vs EGLint)
- the EGL extension list before creating an EGLDisplay differs from the
extension list after (i.e. display vs client extensions)
- all of the above happens in a single SDL_CreateWindow call
This leaves no place for the application to discover what EGL extensions
are available and provide custom attribute lists.
Until now, if a developer wants to add a custom EGL attribute for
eglGetPlatformDisplay, eglCreateWindowSurface or eglCreateContext, they
needed to patch SDL itself. This is very undesirable, since such
developers would have to disable the SDL dynapi in order to maintain
compatibility with their needs.
This patch implements some callbacks which developers can use to
dynamically generate custom EGL attributes for SDL to use during
SDL_CreateWindow.
These functions allow applications to call EGL functions against the SDL
EGL context. For example, applications can use an EGL API loader via
SDL_EGL_GetCurrentDisplay and SDL_EGL_GetProcAddress, and can call
functions such as eglQuerySurface against the internal EGLSurface and
EGLDisplay.
This fallback is undesirable when using ANGLE, because it will end up
using some default configuration (e.g. on Windows it defaults to the
D3D11 backend).
This implements a new SDL_GL_EGL_PLATFORM attribute to set the
"platform" argument for SDL_EGL_LoadLibrary on Windows, macOS, and
Linux. I've limited it to those three operating systems because that's
what I've been able to test against.
This adds support for forcing the use of EGL on Windows and MacOS. The
SDL_HINT_VIDEO_X11_FORCE_EGL hint is retained for backwards
compatibility but is now deprecated.
Downstream distributors can use this to mark a version with their
preferred version information, like a Linux distribution package version
or the Steam revision it was built to be bundled into, or just to mark
it with the vendor it was built by or the environment it's intended to
be used in.
For instance, in Debian I'd use this by configuring with:
--enable-vendor-info="${DEB_VENDOR} ${DEB_VERSION}"
to get a SDL_REVISION like:
release-2.24.1-0-ga1d1946dc (Debian 2.24.1+dfsg-2)
which gives a Debian user enough information to track down the patches
and build-time configuration that were used for package revision 2.
In Autotools and CMake, this is a configure-time option like any other,
and will go into both SDL_REVISION (via SDL_revision.h) and
SDL_GetRevision().
In other build systems (MSVC, Xcode, etc.), defining the
SDL_VENDOR_INFO macro will get it into the output of SDL_GetRevision(),
although not SDL_REVISION.
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of using a URL and git sha1, this uses `git describe` to
describe the version relative to the nearest previous git tag, which
gives a better indication of whether this is a release, a prerelease,
a slightly patched prerelease, or a long way after the last release
during active development.
This serves two purposes: it makes those APIs more informative, and it
also puts this information into the binary in a form that is easy to
screen-scrape using strings(1). For instance, if the bundled version of
SDL in a game has this, we can see at a glance what version it is.
It's also shorter than using the web address of the origin git
repository and the full git commit sha1.
Also write the computed version into a file ./VERSION in `make dist`
tarballs, so that when we build from a tarball on a system that doesn't
have git available, we still get the version details.
For the Perforce code path in showrev.sh, output the version number
followed by the Perforce revision, in a format reminiscent of
`git describe` (with p instead of g to indicate Perforce).
For the code path with no VCS available at all, put a suffix on the
version number to indicate that this is just a guess (we can't know
whether this SDL version is actually a git snapshot or has been
patched locally or similar).
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
Disabling RAWINPUT on Windows 10 causes these issues:
* All Xbox controllers are named "XInput Controller".
* Trigger rumble no longer works.
* "XInput Controllers" are now also listed as separate haptic devices
It's only needed to support more than 4 Xbox controllers, and adds significant complexity to the joystick processing, and we regularly get bugs from people who aren't using an SDL window who need to turn on SDL_HINT_JOYSTICK_THREAD.
* Consolidated scancode mapping tables into a single location for all backends
* Verified that the xfree86_scancode_table2 is largely identical to the Linux scancode table
* Updated the Linux scancode table with the latest kernel keycodes (still unmapped)
* Route X11 keysym -> scancode mapping through the linux scancode table (which a few hand-written exceptions), which will allow mappings to automatically get picked up as they are added in the Linux scancode table
* Disabled verbose reporting of missing keysym mappings, we have enough data for now
