find_lib() uses sort -V, which is a GNU extension. Users of non-GNU
operating systems should either install GNU coreutils (assumed to
provide a gsort executable), or use the CMake build system.
Resolves: https://github.com/libsdl-org/SDL/issues/6106
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the width is sufficiently ludicrous, then the calculated pitch or
the image size could conceivably be a signed integer overflow, which
is undefined behaviour. Calculate in the unsigned size_t domain, with
overflow checks.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When SDL is built with Wayland support on Linux, and Wayland libraries
are linked as dependencies instead of being loaded with dlopen(), its
dependencies will include libraries whose names contain a dash, like
`-lwayland-client` and `-ldecor-0`. Don't replace such libraries with
`-lwayland` and `-ldecor`: those don't exist and linking them will fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On filesystems with large inode numbers, such as overlayfs, attempting
to stat() a file on a 32-bit system using legacy syscalls can fail
with EOVERFLOW. If we opt-in to more modern "large file support"
syscalls, then source code references to functions like stat() are
transparently replaced with ABIs that support large file sizes and
inode numbers, such as stat64().
This cannot safely be done globally by Linux distributions, because
some libraries expose types like `off_t` or `struct stat` in their
ABI, meaning that enabling large file support would be an incompatible
change that would cause crashes. However, SDL appears to be careful to
avoid these types in header files, so it should be OK to enable this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Since #5602, SDL is intended to have the same ABI across the whole
major-version 2 cycle, so we should not check that the minor version
matches the one that was used to compile an application.
There are two checks that could make sense here.
The first check is that the major version matches the expected major
version. This is usually unnecessary and is not usually done (if we're
calling into the wrong library we'll likely crash anyway), but since we
have the information, we might as well continue to use it.
The second check is whether the version provided by the caller is
equal to or greater than a threshold version at which additional fields
were added to the struct. If it is, we should populate those fields;
if it is not, then we cannot. This is only useful on platforms where
additional fields have genuinely been added during the lifetime of
SDL 2, like Windows and DirectFB (but not X11).
This commit changes the first check to be consistent about only looking
at the minor version, while leaving the second check using SDL_VERSIONNUM
(which will be removed or widened in SDL 3, but it's fine for now).
Resolves: https://github.com/libsdl-org/SDL/issues/5711
Fixes: cd7c2f1 "Switch versioning scheme to be the same as GLib and Flatpak"
Signed-off-by: Simon McVittie <smcv@collabora.com>
I had assumed that only Linux users would be interested in GNOME-style
installed-tests, but in principle there's no reason why they can't be
used on non-Linux.
Signed-off-by: Simon McVittie <smcv@collabora.com>
See editorconfig.org for details of the format, which is understood by
multiple text editors, either directly or via plugins.
This is not comprehensive, but should cover most of the SDL codebase.
Please extend as needed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the size to be allocated is very large and untrusted, then adding
the padding etc. might be enough to cause unsigned overflow, after
which a very small amount of memory will be allocated.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This can be used to check whether untrusted sizes would cause overflow
when used to calculate how much memory is needed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The official source code release isn't much use unless it contains
everything that users and downstream distributions need to do a
new build, so check that it does.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The use of square brackets for a character set collides with the use
of square brackets for m4 quote characters, so use the other quoting
mechanism that Autoconf provides, by escaping `[` as `@<:@` and so on.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is currently only done for the Linux Autotools build. The CMake
build does not add a significant amount of extra test coverage, and
Github Workflows run in an environment where `cmake` and `sudo cmake`
point to different executables, which makes it awkward to install into
/usr/local from CMake.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it more convenient to compile them alongside SDL, install
them in an optional package and use them as smoke-tests or diagnostic
tools. The default installation directory is taken from GNOME's
installed-tests, which seems as good a convention as any other:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
Signed-off-by: Simon McVittie <smcv@collabora.com>
As well as reducing duplication, this lets the tests load their resources
from the SDL_GetBasePath() on platforms that support it, which is useful
if the tests are compiled along with the rest of SDL and installed below
/usr as manual tests, similar to GNOME's installed-tests convention.
Thanks to Ozkan Sezer for the OS/2 build glue.
Co-authored-by: Ozkan Sezer <sezeroz@gmail.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
In Autotools, these are run by `make -C ${builddir}/test check`.
In CMake, they're run by `make -C ${builddir} test` or
`ninja -C ${builddir} test` or `ctest --test-dir ${builddir}`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some CI workers don't seem to understand `cmake -v`, and Windows' shell
doesn't understand `VERBOSE=1 cmake`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're strict about applying something resembling semantic versioning
to the "marketing" version number, then we can mechanically generate
the ABI version from it.
This limits the range of valid micro versions (patchlevels) to 0-99.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For stable releases, this gives us the ability to make bugfix-only point
releases such as 2.24.1 if we want to, and distinguish between them
programmatically. For example, this ability could have been useful after
2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop
regressions.
For development releases, this gives us the ability to make multiple
prereleases during the same feature cycle, and distinguish between them
programmatically. For example, this would have been useful during 2.0.22
development, which went through three prereleases before reaching the
final release.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we've said this will be removed from SDL 3, we're free to use
any encoding that is compatible with existing SDL versions and will still
compare correctly for all SDL 2 version numbers. This allows the SDL 2
minor version to go beyond 1 digit, limited only by the size of
SDL_version.minor (which is 8 bits), making the largest possible version
number 2.255.99.
The patchlevel (micro version) is still limited to 2 digits.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The encoding used in SDL_VERSIONNUM (e.g. 2.0.22 -> 2022) cannot
represent 2-digit minor versions without overflowing from the hundreds
digit into the thousands digit, which produces confusing version
numbers that will compare incorrectly when the major version is increased
to 3.
However, we can sidestep this problem by declaring that SDL_VERSIONNUM
will no longer be present in SDL 3, which means it only needs to be able
to represent SDL 2 version numbers losslessly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This comparison normally happens at compile-time, not at runtime, so
it doesn't matter if it isn't optimal. This avoids incorrect comparison
if the minor version in SDL_COMPILEDVERSION and SDL_VERSIONNUM has more
than one digit, which would cause it to overflow from the hundreds place
into the thousands place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is usually desirable for batch processing: it lets us see exactly
what is happening in the logs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It looks as though something in the test subproject "leaks" into the
main build system, causing us to try to install ${builddir}/test/sdl2.pc
instead of the correct ${builddir}/sdl2.pc. Moving the tests subproject
further down avoids this.
Resolves: https://github.com/libsdl-org/SDL/issues/5604
Signed-off-by: Simon McVittie <smcv@collabora.com>
At the time I contributed this unit test, SDL had a relatively narrow
definition of what is a keyboard, approximately matching udev
ID_INPUT_KEYBOARD. Now it uses the equivalent of udev ID_INPUT_KEY,
which matches anything with keyboard keys, and not just reasonably
complete alphanumeric keyboards.
Fixes: 040bd7a9 "Fix udev not detecting ID_INPUT_KEY devices when udev is not running"
Signed-off-by: Simon McVittie <smcv@collabora.com>
At the time I contributed this unit test, SDL didn't understand Linux
touchpads, but now it does.
Fixes: 373216ae "Added support for touchpads in the Linux evdev code"
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using shared linking (linking in the normal way with
-lwayland-client) rather than loading Wayland libraries dynamically at
runtime, listing symbols that don't exist in the current version results
in a build failure. We don't actually call wl_proxy_marshal_flags() or
wl_proxy_marshal_array_flags() directly; the reason we need them is
that they're called by the code generated by wayland-scanner >= 1.20.
If we're building against an older Wayland library, then we'll have its
corresponding version of wayland-scanner (mismatched versions are not
supported), so we won't need those two symbols, and can avoid generating
a dependency on them.
Conversely, if we're building against a newer Wayland library, the
generated code will call them unconditionally, so we cannot treat them as
optional and gracefully fall back: that would result in a crash. Instead,
treat them as a mandatory part of the Wayland library, so that if they
are not found at runtime, we can fall back to X11 without crashing.
libwayland 1.18 is in several LTS distributions (Ubuntu 20.04,
Debian 11, RHEL 8) so avoiding a hard dependency on 1.20 is quite
useful.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://github.com/libsdl-org/SDL/issues/5376
If we are already in the desired mode, changing it is a no-op at best,
and harmful at worst: on Xwayland, it sometimes happens that we disable
the crtc and cannot re-enable it.
Resolves: https://github.com/libsdl-org/SDL/issues/4630
Signed-off-by: Simon McVittie <smcv@collabora.com>
These are explicitly written in C code rather than generated at build
time, so they weren't affected by changing how we invoke
wayland-scanner.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This uses pre-recorded evdev capabilities, so that we can check for
regressions without the devices having to be physically present.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This improves SDL's ability to detect joystick hotplug in a container
environment.
We cannot reliably receive events from udev in a container, because they
are delivered as netlink events, which are authenticated by their uid
being 0. However, in a user namespace created by an unprivileged user
(for example bubblewrap, as used by Flatpak and Steam's
pressure-vessel-wrap), the kernel does not allow us to map uid 0, and
the netlink events appear to be from the kernel's overflowuid (typically
65534/nobody), meaning libudev cannot distinguish between genuine uevents
from udevd and an attack by a malicious local user.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Anything with X, Y and Z axes but no buttons is probably an
accelerometer (this is the assumption made in udev).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we only checked for at least one button or key and at least
the X and Y absolute axes, but this has both false positives and false
negatives.
Graphics tablets, trackpads and touchscreens all have buttons and
absolute X and Y axes, but we don't want to detect those as joysticks.
On normal Linux systems ordinary users do not have access to these
device nodes, but members of the 'input' group do.
Conversely, some game controllers only have digital buttons and no
analogue axes (the Nintendo Wiimote is an example), and some have axes
and no buttons (steering wheels or flight simulator rudders might not
have buttons).
Use the more elaborate heuristic factored out from SDL's udev code path
to handle these cases.
In an ideal world we could use exactly the same heuristic as udev's
input_id builtin, but that isn't under a suitable license for inclusion
in SDL, so we have to use a parallel implementation of something
vaguely similar.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
Device enumeration via libudev can fail in a container for two reasons:
* the netlink protocol between udevd and libudev is considered private,
so there is no API guarantee that the version of libudev in a container
will understand netlink messages from a dissimilar version of udevd
on the host system;
* the netlink protocol between udevd and libudev relies for security on
being able to check the uid of each message, but in a container with
a user namespace where host uid 0 is not mapped, the libudev client
cannot distinguish between messages from host uid 0 and messages from
a different, malicious user on the host
To make this easier to experiment with, always compile the fallback
code path even if libudev is disabled. libudev remains the default if
enabled at compile time, but the fallback code path can be forced.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie