This used a tiny stack, which apparently upsets Blender for various
technical reasons. Instead, just use the default stack size, which should
give it plenty of space to work.
If the thread failed to create, we would then wait on a semaphore that would
never trigger, so don't do that anymore!
Fixes#10806.
(cherry-picked from commit b7dc30ca24)
This reverts commit 9f8dffbd2d.
This causes some tests to fail, and wasn't otherwise a necessary change, so
I'm backing it out.
(Looks like some sort of interaction with software renderers and their
surfaces not getting destroyed...?)
(cherry picked from commit f9a06c20ed)
This allows apps to destroy the window and renderer in either order, but
makes sure that the renderer can properly clean up its resources while OpenGL
contexts and libraries are still loaded, etc.
If the window is destroyed first, the renderer is (mostly) destroyed but its
pointer remains valid. Attempts to use the renderer will return an error,
but it can still be explicitly destroyed, at which time the struct is free'd.
If the renderer is destroyed first, everything works as before, and a new
renderer can still be created on the existing window.
Fixes#10174.
(cherry picked from commit cab3defc18)
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.
Ryan C. Gordon