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>
If a compositor tries to change the decoration mode when initially creating a window, the hidden flag might not yet be unset if the decoration mode is changed during the initial roundtrip in Wayland_ShowWindow(). As hiding the window destroys the decoration manager object, the hidden flag check is unnecessary, as the decoration configuration listener will never be entered when the window is hidden.
(cherry picked from commit 37e1fc3b5894f379f4f8253b867a76a135213a7d)
G923 have two different versions - Xbox version is already present in the wheel list, but not the PS version.
(cherry picked from commit 266b91d2fd2b3362d1828f8a6b58589bdaa4f75d)
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 cde67ea49ad812088bd5c8cfd67ef090ac1c1d86)
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).
Previously it was using setTimeout, not setInterval, so it would only fire
once, which was obviously a mistake.
(cherry picked from commit fb79211732d0cdf17a250a43c619b6938842cfaf)
Since the top-level table is getting undefined, all the things in it will
be unreachable and eligible for garbage collection without explicitly
nulling them out.
(cherry picked from commit 5191b20541fce0e3b3071124ced69c31fcaeb783)
Now, if the AudioContext starts in a "suspended" state, because the browser
blocked it from playing by default, we we run the audio "thread" in a timer
and throw away the generated audio. Once the AudioContext is allowed to
resume, we clear this timer.
The end result is that the app will continue to drain its audio queue
instead of consuming more memory over time (and, if it relies on an audio
callback to make progress, continue to run!), with the effect that the
page is merely silent but otherwise functioning as intended.
Once the user interacts with the page and the browser permits the the
AudioContext to run for real, audio should still be in sync, instead of
just starting to play audio that might now be at least several seconds behind.
(cherry picked from commit fd75a4ca05bdbd7b0fecf781e59c77a07d264b16)
An overflow occured in the stdlib_sscanf test, when using msys2 clang32 toolchain.
(cherry picked from commit 342ec5113171214154cb197bb3e0e3a0056ea2ad)
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
Applications that don't specify a rendering flag are likely handling Vulkan/GL themselves, so SDL loading OpenGL by default in this case is unnecessary overhead, and if a render backend requires it, the window will be recreated with the appropriate flags when the renderer is initialized.
(cherry picked from commit 9ab20251277d001ee34caeb59a7eaa54b40af622)
