Whenever I have to fix something endianness-related, I always get
confused about whether the byte-oriented format that guarantees to put
red in byte 0 is RGBA8888 or RGBA32. (The answer is that it's RGBA32.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids assuming that the pixels are suitably aligned for direct
access, which there's no guarantee that they are; in particular,
3-bytes-per-pixel RGB images are likely to have 3 out of 4 pixels
misaligned. On x86, dereferencing a misaligned pointer does what you
would expect, but on other architectures it's undefined whether it will
work, crash with SIGBUS, or silently give a wrong answer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This shares its implementation with SDLTest_ReadSurfacePixel: the same
code is compiled twice, to get it into the static test library and also
the public shared library.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is essentially the same as was added in d95d2d70, but with clearer
error handling. It's implemented in a private header file so that it
can be shared with SDL_shape, which also wants this functionality.
Resolves: https://github.com/libsdl-org/SDL/issues/8319
Signed-off-by: Simon McVittie <smcv@collabora.com>
When initializing the Wayland driver, check if the application is being started in, or trying to connect to, a Wayland session and skip to another driver if not. If neither WAYLAND_DISPLAY nor XDG_SESSION_TYPE are set, try to start anyway, and if the Wayland library is missing or no Wayland sessions are started, initialization will fail later in the process as it previously did.
This fixes the case where a Wayland session is running on a different VT, but an application wishes to run via KMSDRM on the current VT.
This is an attempt to centralize all the error handling, instead of
implicitly counting on WaitDevice implementations to disconnect the device
to report an error.
This should retry until GetCurrentPosition succeeds. Otherwise, we would be
going on to the next iteration too soon.
Also generally streamlined the code while I was in here.
This prevents catastrophe if someone tries to close the device in an event
filter in response to the event.
Note that this means SDL_GetAudioStreamDevice() for any stream on this
device will return 0 during the event filter!
Fixes#8331.
Android claims to work with multiple devices, but doesn't actually appear to
(at least, afaict), and it will report tons of devices that all just seem
to play to the current default output, so for now, turn this off and only
expose a default device.
And then, with that default output, attempt to recover on errors by throwing
away the current AAudioStream and building a new one.
This let me plug/unplug a set of headphones from the headphone jack and audio
would switch correctly to the new output.
Now we sleep the thread in WaitDevice until ALSA reawakens it because it
needs more data, and we feed it exactly as much as it can take at that
point.
Like the recent PulseAudio changes, this is both more efficient, reliable,
and consistent.
In practice, this seems to buffer a little upfront and then gives a pretty
consistent request flow after that of 1/4 of the requested buffer size without
variation, which is significantly better than the previous code that would
vary a little each frame.
Plus, as long as the device asks for _anything_, we won't block forever, and
if it asks for more than our expected buffer size, we'll run multiple times
to satisfy it, so this is likely more robust against dropouts in general, too.
Previously, if acting on a surface with less than 32 bits per pixel,
this code was placing the pixel value from the surface in the first
few bytes of the Uint32 to be decoded, and unrelated data from a
subsequent pixel in the remaining bytes.
Because SDL_GetRGBA takes the bits to be decoded from the
least-significant bits of the given value, ignoring the higher-order
bits if any, this happened to be correct on little-endian platforms,
where the first few bytes store the least-significant bits of an
integer.
However, it was incorrect on big-endian, where the first few bytes are
the most-significant bits of an integer.
The previous implementation also assumed that unaligned access to a
32-bit quantity is possible, which is not the case on all CPUs (but
happens to be true on x86).
These issues were not discovered until now because
SDLTest_CompareSurfaces() is only used in testautomation, which until
recently was not being run routinely at build-time, because it contained
other assumptions that can fail in an autobuilder or CI environment.
Resolves: https://github.com/libsdl-org/SDL/issues/8315
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sam Lantinga