Previously, each backend would allocate and free the renderer struct. Now
the higher level does it, so the backends only manage their private resources.
This removes some boilerplate and avoids some potential accidents.
(Manually cherry-picked from 39c8434f5f)
Reference Issue #10174.
I _did_ appreciate the explanation, but it doesn't have to live in the
source code; also we can just release `devuid` and then check for error with
the usual macro, since SDL is done with it either way at this point.
(cherry picked from commit 17af09f3a9)
HIDAPI's source code licensing says this:
```
HIDAPI can be used under one of three licenses.
1. The GNU General Public License, version 3.0, in LICENSE-gpl3.txt
2. A BSD-Style License, in LICENSE-bsd.txt.
3. The more liberal original HIDAPI license. LICENSE-orig.txt
The license chosen is at the discretion of the user of HIDAPI. For example:
1. An author of GPL software would likely use HIDAPI under the terms of the
GPL.
2. An author of commercial closed-source software would likely use HIDAPI
under the terms of the BSD-style license or the original HIDAPI license.
```
Since the original license in LICENSE-orig.txt is basically only clause 3 of
the zlib license (do not remove this notice from the source code), it makes
sense to switch to it, since it adds no new requirements to the user.
(Plus, it's extremely short and direct, which is always nice.)
The entire license:
```
HIDAPI - Multi-Platform library for
communication with HID devices.
Copyright 2009, Alan Ott, Signal 11 Software.
All Rights Reserved.
This software may be used by anyone for any reason so
long as the copyright notice in the source files
remains intact.
```
Fixes#9786.
(cherry picked from commit dd09d4b4ee)
This changes the `SDL_EVENTS_DISABLED` path's return value from SDL_DISABLE
to SDL_IGNORE to match expectations, but doesn't actually change the ABI,
since these two symbols are both zero.
Fixes https://github.com/libsdl-org/sdlwiki/issues/460
The public headers saw lots of cleanups, backporting from SDL3 docs, and
merging with the wiki.
The markdown files in docs/README-*.md were converted to Unix endlines.
- Move legacy name choice to a separate function, so we can `return` a
string in one line instead of assign a variable and `break` for each item.
- Have the case statement cover SDL_NUM_SYSTEM_CURSORS, and not `default`, so
compiler will (maybe) warn us if an enum value is added but not included here.
- Only choose a legacy name if necessary.
SDL3's Wayland code already uses the CSS names exclusively with no
fallback, but since SDL2 has historically used the older names, keeping
them as a fallback makes sense if the CSS names don't work out.
[smcv: Added commit message]
Tested-by: Simon McVittie <smcv@collabora.com>
Apparently this is necessary on the latest Gnome to get properly themed
cursors, vs ancient X11 standard cursors, as Gnome has dropped the old
theme names that XCreateFontCursor eventually expected to find.
Fixes#8939.
(cherry picked from commit cb9565354c)
Note that apparently this has caused some weird-sounding audio
on some Android devices, so we might wrap this in a hint later,
or try to check for specific devices.
Fixes#8888.
Otherwise we'll miss it when XWarpPointer() is used. x11vnc may do this to
manage mouse input in some circumstances, so it can be possible for _all_
mouse motion to go through this path, breaking SDL_GetGlobalMouseState().
Thanks to @chrismile for all the detective work to figure this out!
Fixes#8827.
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.
Mesa and Nvidia handle it differently, and one or the other may fix their
implementation in the future, so test which way it works at runtime.
Reference Issue #8004.
(cherry picked from commit 74a2542564)
This specifically fixes a crash in X11_WarpMouseInternal if XInput2 was
missing at runtime, but also cleans up a few other existing checks.
Fixes#8378.
(cherry picked from commit 82f54af617)
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 5191b20541)
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 fd75a4ca05)
- Make sure the hotplug thread has hit its main loop before letting
DetectDevices continue.
- Don't unref the context subscription operation until it completes
(or we are shutting down).
I'm not sure which change fixed the problem, but at least one of them
appears to have done so.
Reference Issue #7971.
This risks blocking the thread if disaster ensues, and we can wait in the
thread's main loop for subscription as well anywhere else.
Reference Issue #7971.
(cherry picked from commit 956b18f50c)
This used to create a context and mainloop for each device and the hotplug
thread, but this isn't correct use of PulseAudio's API. Now we have a
single context and a pa_threaded_mainloop, and all threads cooperate around
it.
This was originally from SDL3, in 35292d7dba.
Reference Issue #7883.
Reference Issue #7427.
This prevents the case where the mouse might be at the edge of the
window when enabling relative mode, which confuses macOS, at it
might believe the user is attempting to resize the window.
Fixes#6994.
They can vanish for UP TO EIGHT SECONDS...!
This is for devices that connect to HDMI/DisplayPort/etc, where it
presumably has to wait for a display to get up and running before it
can play audio through it, so one can see the audio device fail when
changing display modes, or the system returning from sleep. Since this
can be triggered by a game changing video resolutions at startup (either
before or after opening the audio device!), it's important to deal with.
In normal conditions, it shouldn't take this long to open or recover an
audio device, but this is better than unexpectedly losing the device
in this situation.
Fixes#7044.
Fixes#5571.
In theory this is illegal, but legit wavefiles in the field do it, and
it's easy to bump it to 1 for general purposes.
Formats with more specific alignment requirements already check for them
separately.
Fixes#7714.
(cherry picked from commit 2e646c7141)
sdl12-compat can get into a state where a color-keyed surface is
marked for blending, but wants to blend with full alpha (which
is the same as _not_ blending), so rather than fail to find a
blitter in that case, it just selects the colorkey blitter.
Reference https://github.com/libsdl-org/sdl12-compat/issues/233
Ryan C. Gordon