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>
(cherry picked from commit d95d2d7051)
(cherry picked from commit 6b5eadb10f)
This allows utilities like clipboard managers to keep track of the
changes.
(cherry picked from commit 65aaf3a9ab)
(cherry picked from commit 70a2ac2f1c)
Battle for Wesnoth apparently relies on being able to disable rendering
of UI elements by setting the clip rectangle to be empty.
Resolves: https://github.com/libsdl-org/SDL/issues/6896
Fixes: 00f05dcf "render: only enable clipping when the rectangle is valid"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8ad043fc38)
G923 have two different versions - Xbox version is already present in the wheel list, but not the PS version.
(cherry picked from commit 266b91d2fd)
(cherry picked from commit 365a36386a)
Logitech PRO Racing Wheel have two different versions - for Playstation and Xbox. Vendor + Product ID for Playstation version already present in SDL sources, but not an Xbox version
(cherry picked from commit cde67ea49a)
(cherry picked from commit 242b25aba4)
On some system like MacBook Pro Intel with AMD card, asking for the default device will always return the AMD GPU.
This is not an issue for 99% of the case when the renderer context is here to provide the maximum performance level like for game.
However, for video application using GPU for 1 quad and 1 texture, using the discrete GPU for that lead to an important power consumption (4 to 8W), heat increase, and fan noise.
With this patch, I successfully amend ffplay to only use the integrated GPU (i.e. the Intel one), instead of the discrete GPU (i.e. the AMD one).
(cherry picked from commit aa7ba62978)
An overflow occured in the stdlib_sscanf test, when using msys2 clang32 toolchain.
(cherry picked from commit 342ec51131)
(cherry picked from commit 10135b2d7b)
Error messages are not part of the ABI, so we can't validate those.
Technically SDL_AllocFormat() on a FOURCC format in SDL2 should fail, but SDL3 supports it and we don't expect SDL2 applications to actually do this, so skip that test.
Hand-picked from 5cf9438f88
Many of the Flydigi controllers use the same VID/PID and have different mappings, so let's revisit this once we have more data.
(cherry picked from commit 5388edd549)
(cherry picked from commit 805fc29ae8)
When a hardware keyboard is attached, it can take over 100 ms for the keyboard event to generate text input. In that case we want to record that we recently received a keyboard event so we don't synthesize duplicate virtual key press/release events for the input text.
(cherry picked from commit 648de4f9b8)
(cherry picked from commit 38c63afd64)
When a hardware keyboard is attached to an iPad, you can easily trigger a set of on-screen keyboard transitions that will take place over time, and we need to track whether we're currently showing or hiding the keyboard and make sure we don't clobber the existing state during those transitions.
Testing:
* Connected a hardware keyboard to an iPad
* Launched checkkeys
* Noted the keyboard bar was active at the bottom of the screen and text input was active
* Tapped with both fingers to quickly toggle text input off and back on
* Noted the keyboard bar slid down and then back up, and text input was active
* Tapped on the keyboard bar to bring up the full on-screen keyboard and then closed it so the keyboard bar was still active, and text input was still active
* Tapped on the screen to turn text input off, noted the keyboard bar slid down
* Tapped with both fingers to quickly toggle text input on and back off
* Noted that the keyboard bar slid up and then back down, and text input was inactive
* Tapped on the screen to turn text input on, tapped on the keyboard bar to bring up the full on-screen keyboard, and text input was active
* Pressed a key on the physical keyboard, the on-screen keyboard closed, the key press and release was delivered (with no text input) and then the keyboard bar slid up, and text input was active again
Fixes https://github.com/libsdl-org/SDL/issues/7979
(cherry picked from commit c3288d113e)
(cherry picked from commit 030bb7282a)
This is another attempt to make sure we don't cause beeps from unhandled key presses while still allowing full text input functionalty.
If this isn't selective enough, we might need to go up the responder chain to see what's going to handle the event before passing it along.
Fixes https://github.com/libsdl-org/SDL/pull/6962
(cherry picked from commit a8abe612ed)
(cherry picked from commit 335e9c769a)
Anonymous Maarten