These are faster and more precise.
This did not change the Uint16 versions (as SDL3 dropped them, and honestly
no one should be using them in SDL2), nor the NEON converters (as this was
not changed in SDL3, so far).
Fixes#8786.
Matches the one in `GetMouseMessageSource()`.
From my testing on Windows 11, the lower 8 bits in touch events cycle
trough the values 0x8c-0x95 in order.
(cherry picked from commit d747daf03d)
like SDL_triangle.c:305:30: runtime error: left shift of negative value -672
(even if the value was correctly computed)
(cherry picked from commit 4033a0a83b)
The previous code was working incorrectly on viewports not having the
top left corner on the origin: even in those cases we only need to look
at the width and height of the viewport, because the drawing coordinates
are translated.
Fixes#8828
AUDIO_F32 is an alias for AUDIO_F32LSB, 32-bit floating point with least
significant byte first, resulting in audio_resampleLoss() failing on
big-endian machines. This particular test generates a buffer with
native-endianness float values, so it ought to be using AUDIO_F32SYS,
which is 32-bit floating point in the native endianness.
Already fixed by commit 47bcb078 "Fixed some incorrect SDL_AUDIO_F32 uses"
on the SDL 3 branch.
Resolves: https://github.com/libsdl-org/SDL/issues/8818
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unlike the test images in the previous commit, this one is
4-bytes-per-pixel RGBA32, so the masks used here appear to be correct
for both endiannesses. Converting it to SDL_PIXELFORMAT_RGBA32 just
makes it more concise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
All of these test images are provided as an octal dump of
3-bytes-per-pixel data with red, green and blue bytes in that order,
referred to as RGB24 in SDL's taxonomy. However, the call to
SDL_CreateRGBSurfaceFrom() used masks that would have been appropriate
for RGBA32 data.
On little-endian platforms, the test images loaded as intended anyway,
because SDL does not actually check all four masks before deciding to
use RGB24 (it only looks at the red mask), and the red channel happens to
be in the 0x000000FF position for both RGB24 and RGBA32 on little-endian.
Unfortunately, on big-endian platforms, the required masks are not the
same and the call failed with "Unknown pixel format". As far as I can
tell, this means testautomation_surface has never succeeded on big-endian
platforms, but presumably nobody has tried to run it on such platforms
until now.
In the SDL 3 branch, this was fixed as a side-effect of commit
932f6134 "Remove mask versions of SDL_CreateRGBSurface* #6701 (#6711)",
which I have used as a reference to confirm that RGB24 is correct.
Resolves: https://github.com/libsdl-org/SDL/issues/8817
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't rely on irrational numbers like pi being represented exactly,
particularly when compiling for i386, where the i387 floating-point
interface carries out calculations in registers that have higher
precision than the actual double-precision variable. The 1980s were a
strange time.
Resolves: https://github.com/libsdl-org/SDL/issues/8311
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 6248472c0c)
If testautomation is running with only a specific audio driver enabled, we shouldn't try to open other ones, as they might fail.
Fixes https://github.com/libsdl-org/SDL/issues/8797
SDL_GetGamepadAxis() is a SDL3-specific name: SDL2 calls gamepads
"game controllers".
Fixes: d3c21666 "gamepad: Clarify range and direction of axes"
Signed-off-by: Simon McVittie <smcv@collabora.com>
When a test has been disabled because it's known not to work reliably
or it's a test for unimplemented functionality, we probably don't want
to encourage developers and testers to run it and report its failures
as a bug.
Helps: #8798, #8800
Signed-off-by: Simon McVittie <smcv@collabora.com>
It would be easy to assume that all APIs that reference
SDL_JOYSTICK_AXIS_MAX work the same way, but they do not: triggers
generally use the full signed 16-bit range in the lower-level joystick
API, but are normalized to be non-negative by the higher-level gamepad
API.
We also never said explicitly which direction is positive here.
Experimentally, it's right (X), down (Y), and pressed (triggers).
Resolves: https://github.com/libsdl-org/SDL/issues/8793
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 059fb560ba)
The ARM926EJ-S Technical Reference Manual states:
> You can only access CP15 registers with MRC and MCR instructions in a
> privileged mode. CDP, LDC, STC, MCRR, and MRRC instructions, and unprivileged
> MRC or MCR instructions to CP15 cause the Undefined instruction exception to
> be taken.
Furthermore, `MCR p15, 0, <Rd>, c7, c10, 5` (later called Data Memory Barrier)
is not specified for the ARM926. Thus, SDL should not use these cache
instructions on ARMv5.
(cherry picked from commit 139a0931a3)
When cross-compiling, pkg.m4 will set the PKG_CONFIG variable
to a suitable pkg-config executable, which might be a
host-architecture-prefixed name like aarch64-linux-gnu-pkg-config. This
ensures that we will use a suitable search path that is suitable for
the host architecture (the machine we are compiling for) rather than
the build architecture (the machine we are compiling on) to find
dependency libraries like SDL. When using pkg-config as a substitute
for sdl2-config, we will similarly need to use the
host-architecture-prefixed pkg-config.
Setting the PKG_CONFIG environment variable is also the canonical way to
request that a different pkg-config implementation be used, if that
becomes necessary for some reason.
Co-authored-by: Helmut Grohne <helmut@subdivi.de>
Bug-Debian: https://bugs.debian.org/1059749
Signed-off-by: Simon McVittie <smcv@collabora.com>
The udev container issue is mostly to do with device notifications
and netlink. The device classification stuff just pokes file in /sys
and /run/udev. Doesn't hurt to try it first for classifying joysticks
and then fall to the guess heuristics if it fails.
Sylvain