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)
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 5388edd5494030b8c43b2f79e3f5c9b71f57a703)
as offscreen is enabled in CMakeLists.txt, we get a blanks window
otherwise.
From a patch by Silvan Scherrer, at Bitwiseworks' fork.
(cherry picked from commit 66d5ad19f0260f42426a66fe664b6e98291faa37)
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 648de4f9b8ebcf9e794aba2ec2955d129167c48b)
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 c3288d113e434b20d2f0dda73210d3a52504d199)
