This was the only API that broke the "GetNumThings" convention
used elsewhere, so renaming it helps with consistency.
Adding "logical cores" to the name also makes it a bit
more immediately obvious what the count actually represents.
This had the unfortunate side-effect of blocking if you tried to write too much. Instead you can use SDL_GetProcessInput() and handle SDL_IO_STATUS_NOT_READY as needed.
Fixes https://github.com/libsdl-org/SDL/issues/10834
Also marked the existing functions as unsafe, as they can cause crashes if used in multi-threaded applications.
As a bonus, since the new functions are hashtable based, hint environment lookups are much faster.
Also added SDL_PROP_IOSTREAM_FILE_DESCRIPTOR_NUMBER and refactored the internal API to be able to create SDL_IOStream objects from native file handles.
In some cases, such as when recreating a window during renderer initialization, a failure can leave the window in a state where the internal structure has already been freed, but the higher level window object needs to be destroyed separately. Check that the internal handle is valid before attempting to access any data during destruction.
Allows for graceful failure instead of a crash during cleanup if renderer creation fails.
Use doubles and apply an offset to account for rounding errors due to Wayland scale increments being in units of 1/120. This fixes the backbuffer size calculations with certain combinations of size/scale values, and future-proofs the Wayland backend, as 32-bit floats become increasingly error-prone with larger dimensions and/or scale factors.
The conversion formula is now point->pixel->point round trip safe as well.
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.
GameInput currently has a bug with keys stuck on focus change, and crashes on initialization on some systems, so we'll disable it until these issues are fixed.
@smcv may have found the root cause of the pipewire thread crash, so removing the pipewire client version check to re-enable use of pipewire in older container runtimes.
hotplug_loop_init() calls pw_context_new(), which creates a thread
internally (for the "data loop"). It also creates a thread of its own,
the `hotplug_loop`.
Both of these threads are running code from libpipewire, so before we
can allow the Pipewire library to be unloaded, we need to destroy
the context with pw_context_destroy() and destroy the `hotplug_loop`
with pw_thread_loop_destroy().
Resolves: https://github.com/libsdl-org/SDL/issues/10787
Signed-off-by: Simon McVittie <smcv@collabora.com>
On most Unix platforms supported by SDL, the canonical name used to load
a library at runtime includes its ABI major version, and the name
without a version is not guaranteed to exist on non-developer systems.
libX11-xcb.so.1 is correct on Linux, and probably on other Unix
platforms like FreeBSD.
A notable exception is OpenBSD, which apparently does not use
ABI-suffixed names, so continue to use libX11-xcb.so there.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When debugging crash reports, it's helpful to know which thread is
associated with which external library.
Linux limits the length of a thread name to 15 bytes (not including the
zero-termination), so abbreviate Pipewire to "pw" and hotplug to "plug"
to fit the desired information into the allowed space.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We make sure we initialize XInput first, so that anything checking whether it's enabled gets a valid result based on whether we were able to load it or not.
- CreateEventEx() is guarded by _WIN32_WINNT >= 0x0600:
In SDL_gpu_d3d12.c, include core/windows/SDL_windows.h
that defines _WIN32_WINNT properly to account for that
- DXGIInfoQueue stuff is not available in all toolchains
such as mingw-w64 version 8.0.3
- SDL_gpu_d3d11.c: _WIN32 is always defined by MinGW, as
is the case for all windows-targeting compilers, so it
doesn't guarantee absence of DXGIInfoQueue stuff:
rely on __IDXGIInfoQueue_INTERFACE_DEFINED__, as it is
done elsewhere.
Fixes: https://github.com/libsdl-org/SDL/issues/10705 .
Allow setting a parent/child relationship on toplevel windows, which allows raising sets of windows together, and allows child windows to always float above their parents.
Modal windows are now set by setting the parent, then toggling modal status, as the previous interface duplicated functionality now handled by SDL_SetWindowParent().
The default value of MAX_FRAMES_IN_FLIGHT (3) may be less than the
minImageCount returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR() on
some setups. For example, the Intel IVB Vulkan driver on Wayland returns
a minImageCount of 4, resulting in the following validation warning:
VUID-VkSwapchainCreateInfoKHR-presentMode-02839(ERROR / SPEC): msgNum: -76493605 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-presentMode-02839 ] | MessageID = 0xfb70ccdb | vkCreateSwapchainKHR(): pCreateInfo->minImageCount 3, which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR() (i.e. minImageCount = 4, maxImageCount = 0). The Vulkan spec states: If presentMode is not VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR nor VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR, then minImageCount must be greater than or equal to the value returned in the minImageCount member of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-presentMode-02839)
Objects: 0
Use the minimum image count in that case, as it's as close as we'll get
to our preferred value. Note also that, unlike maxImageCount,
minImageCount is never 0 (the spec states it is always at least 1), so
we don't need a similar check to see if it applies.
Signed-off-by: David Gow <david@ingeniumdigital.com>
The `colorAttachmentDescriptions` field of `SDL_GPUGraphicsPipelineAttachmentInfo` should be marked `const`,
similarly to the `vertexBindings` and `vertexAttributes` fields of `SDL_GPUVertexInputState`.
Using the @() syntax to construct an NSString assumes the parenthesized
pointer is null-terminated, but the Metal shader source included in
render/sdlgpu/shaders/metal.h is not null-terminated.
Quoting the clang documentation on Objective-C literals:
When the type of the parenthesized expression is (char *) or (const
char *), the result of the boxed expression is a pointer to an
NSString object containing equivalent character data, which is
assumed to be ‘\0’-terminated and UTF-8 encoded.
Because the @() syntax assumes null-termination, it may read garbage
data after the shader source (up to the next null byte), which can then
cause the Metal shader compiler to fail. To prevent this, instead of
using the @() boxing syntax, we explicitly construct an NSString using
the string length passed by the caller.
These functions had special cases for a few BC formats, but all
block-compressed formats should need the same logic. Furthermore they
weren't handling the sRGB variants of those formats.
OutputDebugString and fprintf(stderr) (of mslibc) both output
to the debug window of Visual Studio.
In other debuggers (e.g. RAD), this does not happen.
To avoid double output, this commit always uses WriteFile/WriteConsole.
Sam Lantinga
Anonymous Maarten
Carl Åstholm
Ozkan Sezer
ritalat
Semphriss
Semphris
Ethan Lee
Frank Praznik
Caleb Cornett
poleonek
Ryan C. Gordon
Evan Hemsley
hwsmm
Petar Popovic
Andrei Alexeyev
cosmonaut
Simon McVittie
Daniel Ludwig
Timothee Besset
David Gow
Sylvain
Quinn X. J.
Davis Gallinghouse
Zero
coffeechriph