If we get ENOENT we call that success. If the parent directory doesn't exist, that's fine, other operations on it will fail if it matters to the application.
Some POSIX platforms don't define macros to note the presence of the POSIX.1-2008 st_*tim timespec members of the stat struct, so check if this member exists during CMake configuration and conditionally enable it.
Apple platforms use st_*timespec naming, which is supported as of OSX 10.6. SDL3 requires 10.9+, so no fallback is needed.
Android only supports the POSIX.1-2008 semantics as of API version 26 or higher, so this has to be conditionally enabled in the makefile build via an API version definition check.
In other cases, file times fall back to the legacy path with second precision.
Adds functions to query the system's realtime clock, convert time intervals to/from a calendar date and time in either UTC or the local time, and perform time related calculations.
An SDL_Time type (a time interval represented in nanoseconds), and SDL_DateTime struct (broken down calendar date and time) were added to facilitate this functionality.
Querying the system time results in a value expressed in nanoseconds since the Unix epoch (Jan 1, 1970) in UTC +0000. Conversions to and from the various platform epochs and units are performed when required.
Any direct handling of timezones and DST were intentionally avoided. The offset from UTC is provided when converting from UTC to a local time by calculating the difference between the original UTC and the resulting local time, but no other timezone or DST information is used.
The preferred date formatting and 12/24 hour time for the system locale can be retrieved via global preferences.
Helper functions for obtaining the day of week or day or year for calendar date, and getting the number of days in a month in a given year are provided for convenience. These are simple, but useful for performing various time related calculations.
An automated test for time conversion is included, as is a simple standalone test to display the current system date and time onscreen along with a calendar, the rendering of which demonstrates the use of the utility functions (press up/down to increment or decrement the current month, and keys 1-5 to change the date and time formats).
By using the SDL_WaitEventTimeout_Device() path even when polling is required,
we can still achieve sub-millisecond latency for non-gamepad/sensor events when
a gamepad or sensor is in use by the application.
using the blocking sceCtrlReadBufferPositive() effectively turns SDL_PollEvent() into WaitForVblank(), because the functions does exactly that if no input is buffered.
due to this, calling SDL_PollEvent() once per frame averaged in 7 ms delay out of the available 16ms budget to get a frame calculated and drawn to achieve 60 fps.
(cherry picked from commit 86f223d66426ad1a42db156d1f1d155ad987959b)
This removes the "FSops" naming scheme, which was meant to mirror the
"RWops" naming scheme, which was also recently removed from SDL3.
The build system defines (`SDL_FSOPS_POSIX`, etc) and the source code
filenames retain this, because there's already things using the word
"filesystem" that might overlap (for example, lots of things have a
unique "SDL_sysfilesystem.c", to query base dirs, etc, but almost
everything uses the POSIX "SDL_sysfsops.c" source code.
Fixes#9288.
If someone needs to, say, include an SDL_Storage object, they can simply point userdata at a structure that includes the the storage and any other data needed in enumeration.
Pass the Wayland window export string in the form "wayland:<handle string>" or the X11 window XID in the form "x11:<XID in hex>" to the file dialog portal, so that the window manager can associate the dialog with the parent window and position it correctly.
Add the xdg-foreign-unstable-v2 protocol and use it to create export handles for toplevel windows, which will be used when an external component, such as the file chooser portal, requires it.
- SDL_RWops is now an opaque struct.
- SDL_AllocRW is gone. If an app is creating a custom RWops, they pass the
function pointers to SDL_CreateRW(), which are stored internally.
- SDL_RWclose is gone, there is only SDL_DestroyRW(), which calls the
implementation's `->close` method before freeing other things.
- There is only one path to create and use RWops now, so we don't have to
worry about whether `->close` will call SDL_DestroyRW, or if this will
risk any Properties not being released, etc.
- SDL_RWFrom* still works as expected, for getting a RWops without having
to supply your own implementation. Objects from these functions are also
destroyed with SDL_DestroyRW.
- Lots of other cleanup and SDL3ization of the library code.
The CRC is used to distinguish between different controllers that have the same VID/PID, so if the CRC doesn't match, it's probably a different controller that we don't know about.
Fixes https://github.com/libsdl-org/SDL/issues/9265
Use memfd_create() to allocate the temporary SHM backing file in memory, and set the size with posix_fallocate(), which will return an error on insufficient space vs ftruncate(), which will silently succeed and allow a SIGBUS error to occur if the unbacked memory is accessed.
Additionally, make the legacy path more robust by unlinking the temp file, so it won't persist after close, and unmapping the shared memory buffer.
This broke support for the Hori Fighting Stick EX2, which gets a good mapping if the automatic mapping is allowed to create one.
If the original controller needs a mapping, it should be added with a crc, since that VID/PID combination is used by several HORI controllers.
While the focus change happens, Windows appears to reset the cursor clip rectangle, and then restore it if the application that has focus has the clip rectangle set.
This fixes resetting the clip rectangle while changing focus between windows in the same application, e.g. the Source 2 editor.
This adds HIDAPI support for DualShock 3 controllers on Windows, addressing the current absence of this feature in SDL. To utilize this functionality, the official Sony driver 'sixaxis.sys' must be installed. HID offers several advantages over DirectInput, including rumble support and the ability to control the LED lights that display the controller number.
On Android, HIDAPI prompts for permissions and acquires exclusive access to the device, and on Apple mobile platforms it doesn't do anything except for handling Bluetooth Steam Controllers.
Fixes https://github.com/libsdl-org/SDL/issues/9241
Previously there were two different paths for renderer creation, and the HDR metadata initialization was missing when creating a software renderer for a surface. Now all the cases are handled in a single path, so regardless of whether you create a software renderer by name, a software renderer for a surface, or fall back to a software renderer, you'll get the correct initialization in all cases.
Fixes https://github.com/libsdl-org/SDL/issues/9221
Since commit 0dfdf1f3 "Fixed crash if joystick functions are passed a
NULL joystick", we've already done this check by the time we get to
this point.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Separately checking the state of a file before operating on it may allow
an attacker to modify the file between the two operations. (CWE-367)
Fix by using fstat() instead of stat().
Found in the wild from minidump reports. Unclear displaydata is null, but according
to the API it is possible for this call to return null so it seems like a valid check.
When the titlebar drage region is clicked two actions are triggered:
* The WM transfers focus to the application
* The application starts a drag operation because the drag region was clicked
When the drag operation starts before input has been transferred to the application the
window manager gets in a bad state where mouse clicks don't work and the system isn't
actually dragging.
In this CL we delay drag operations until after the application has acquired active focus.
This fixes the problems outlined above.
Alter the video driver grab/confinement function signatures to return an int, set and return an error if the grab request fails, and clear the grab flags from the window if the mouse and/or keyboard wasn't actually grabbed.
This merges mainstream commit
4f2e91bae8
(authored by Vladimir Gladkov) into ours. From the original commit log:
Win32 HID API doc says: For USB devices, the maximum string length is
126 wide characters (not including the terminating NULL character).
For certain USB devices, using a buffer larger or equal to 127 wchars
results in successful completion of HID API functions, but a broken
string is stored in the output buffer. This behaviour persists even if
HID API is bypassed and HID IOCTLs are passed to the HID driver directly
(IOCTL_HID_GET_MANUFACTURER_STRING, IOCTL_HID_GET_PRODUCT_STRING, etc).
So, the buffer MUST NOT exceed 126 wchars.
windows: refactor ULONGLONG hid_internal_get_info(...) ->
hid_internal_detect_bus_type_result hid_internal_detect_bus_type(...)
hid_internal_detect_bus_type is now only responsible for detection of
the bus type; rename it accordingly. Also, mixing an internal flag and
DEV_INST into an ULONGLONG retval feels kinda hackish; use a cleaner
approach instead (add an internal flag to help distinguishing between
BLUETOOTH and BLE devices, then clear it once we are done).
Other flags may have been set when programmatically hiding a window, so or in the fullscreen and maximized flags to avoid accidentally clearing any others.
The window manager might hide/unmap the window when it is minimized, in which case the fullscreen and maximized flags must be preserved as pending flags so the window will be restored to the proper state when shown/mapped on restoration.
We were accidentally skipping all of the mappings that used the SDL_GAMECONTROLLER_USE_BUTTON_LABELS hint, because they used the '!' negate operator with a default hint value of 1. Instead we just want to use that hint to determine whether the mapping has positional buttons or not, and swap the buttons as needed.
Fixes https://github.com/libsdl-org/SDL/issues/9190
This uses the same chipset as the DragonRise Inc. Generic USB Joystick, which many manufacturers use for different products with different mappings.
In order to add a mapping for a controller using this chipset, we need a unique crc for the device name.
- Always use internal qsort and bsearch implementation.
- add "_r" reentrant versions.
The reasons for always using the internal versions is that the C runtime
versions' callbacks are not mark STDCALL, so we would have add bridge
functions for them anyhow, The C runtime qsort_r/qsort_s have different
orders of arguments on different platforms, and most importantly: qsort()
isn't a stable sort, and isn't guaranteed to give the same ordering for
two objects marked as equal by the callback...as such, Visual Studio and
glibc can give different sort results for the same data set...in this
sense, having one piece of code shared on all platforms makes sense here,
for reliabillity.
bsearch does not have a standard _r version at all, and suffers from the
same SDLCALL concern. Since the code is simple and we would have to work
around the C runtime, it's easier to just go with the built-in function
and remove all the CMake C runtime tests.
Fixes#9159.
* Make sure to always write pointSize in VS (fixes validation error in testsprite)
* Fix validation error from acquiring swapchain semaphore more than once
* Fix validation error from using incorrect framebuffer size in testautomation
Now passes testautomation with validation.
* Vulkan Renderer - implement YcBcCr using VK_KHR_sampler_ycbcr_conversion. This simplifies the shader code and will also allow support for additional formats that we don't yet support (such as SDL_PIXELFORMAT_P010 for ffmpeg). The renderer now queries for VK_KHR_sampler_ycbcr_conversion and dependent extensions and will enable it if it's present. It reimplements YUV/NV12 texture support using this extension (these formats are no longer supported if the extension is not present). For each YUV/NV12 texture, a VkSamplerYcbcrConversion object is created from SDL_Colorspace parameters. This is passed to the VkImageView and also an additional sampler is created for Ycbcr. Instead of using 1-3 textures, the shaders now all use 1 texture with a combined image sampler (required by the extension). Further, when using Ycbcr, a separate descriptor set layout is baked with the Ycbcr sampler as an immutable sampler. The code to copy the images now copies to the individual image planes. The swizzling between formats is handled in the VkSamplerYcbcrConversion object.
The removal of a wl_output may not be accompanied by leave events for the surfaces present on it. Ensure that no window continues to hold a reference to a removed output.
The VULKAN_InvalidateCachedState() function seems to be meant to
invalidate any _cached_ state, i.e. global state of the API which may
have been modified outside the renderer.
However, at the moment, the Vulkan renderer also resets a number of
internal variables which track buffers, offsets, etc, in use. As a
result, the renderer can get into an inconsistant state and/or lose
data.
For example, if VULKAN_InvalidateCachedState() is called in between two
calls to VULKAN_UpdateVertexBuffer(), the data from the first call will
be overwritten by that from the second, as the number of the next vertex
buffer to use will be reset to 0. This can result in rendering errors,
as the same vertex data is used incorrectly for several calls.
By no longer resetting this 'internal' state here, those glitches
disappear. However, I haven't tested this with any applications which
mix the Vulkan renderer with their own Vulkan code (do any such
applications exist?), so this may be insufficient in case a full flush
of the renderer state -- and possibly a wait on the appropriate fence
-- could be required.
Signed-off-by: David Gow <david@ingeniumdigital.com>
When selecting a memory type, there are some property flags we need
(e.g., VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, without which we cannot
vkMapMemory), and others we'd simply prefer (e.g.,
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, which may have a performance
impact, but otherwise shouldn't be required).
By specifying these separately, we can fall back to a memory type which
doesn't have everything we want, but which should still work, rather
than giving up.
Signed-off-by: David Gow <david@ingeniumdigital.com>
VULKAN_FindMemoryTypeIndex() tries first to get a perfectly matching
memory type, then falls back to selecting any memory type which overlaps
with the requested flags.
However, some of the flags requested are actually required, so if -- for
example -- we request a memory type with
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, but get one without it, all future
calls to vkMapMemory() will fail with:
```
vkMapMemory(): Mapping memory without VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set. Memory has type 0 which has properties VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT. The Vulkan spec states:
memory must have been created with a memory type that reports VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT.
```
(This occurs, for instance, on the totally non-conformant hasvk driver
for Intel Haswell integrated GPUs, which otherwise works fine.)
Instead, make sure that any memory type found has a superset of the
requested flags, so it'll always be appropriate.
Of course, this makes it _less_ likely for a memory type to be found, so
it does make #9130 worse in some ways. See the next patch for details.
Signed-off-by: David Gow <david@ingeniumdigital.com>
When enabling the Vulkan validation layers, the 'validationLayerName'
variable technically went out of scope before vkCreateInstance() was
called. While most compilers won't clean up stack variables after random
'if' statements, some will, particularly when optimisation or memory
sanitizers are enabled.
This can lead to vkCreateInstance() segfaulting when
SDL_HINT_RENDER_VULKAN_DEBUG is enabled.
Instead, make the validationLayerName visible throughout the entire
VULKAN_CreateDeviceResources() function.
While we're at it, extract the validation layer name out into a
preprocessor #define, so that we are definitely using the same name in
VULKAN_ValidationLayersFound().
Signed-off-by: David Gow <david@ingeniumdigital.com>
This pull request adds an implementation of a Vulkan Render backend to SDL. I have so far tested this primarily on Windows, but also smoke tested on Linux and macOS (MoltenVK). I have not tried it yet on Android, but it should be usable there as well (sans any bugs I missed). This began as a port of the SDL Direct3D12 Renderer, which is the closest thing to Vulkan as existed in the SDL codebase. The shaders are more or less identical (with the only differences being in descriptor bindings vs root descriptors). The shaders are built using the HLSL frontend of glslang.
Everything in the code is pure Vulkan 1.0 (no extensions), with the exception of HDR support which requires the Vulkan instance extension `VK_EXT_swapchain_colorspace`. The code could have been simplified considerably if I used dynamic rendering, push descriptors, extended dynamic state, and other modern Vulkan-isms, but I felt it was more important to make the code as vanilla Vulkan as possible so that it would run on any Vulkan implementation.
The main differences with the Direct3D12 renderer are:
* Having to manage renderpasses for performing clears. There is likely some optimization that would still remain for more efficient use of TBDR hardware where there might be some unnecessary load/stores, but it does attempt to do clears using renderpasses.
* Constant buffer data couldn't be directly updated in the command buffer since I didn't want to rely on push descriptors, so there is a persistently mapped buffer with increasing offset per swapchain image where CB data gets written.
* Many more resources are dependent on the swapchain resizing due to i.e. Vulkan requiring the VkFramebuffer to reference the VkImageView of the swapchain, so there is a bit more code around handling that than was necessary in D3D12.
* For NV12/NV21 textures, rather than there being plane data in the texture itself, the UV data is placed in a separate `VkImage`/`VkImageView`.
I've verified that `testcolorspace` works with both sRGB and HDR linear. I've tested `testoverlay` works with the various YUV/NV12/NV21 formats. I've tested `testsprite`. I've checked that window resizing and swapchain out-of-date handling when minimizing are working. I've run through `testautomation` with the render tests. I also have run several of the tests with Vulkan validation and synchronization validation. Surely I will have missed some things, but I think it's in a good state to be merged and build out from here.
This better reflects how HDR content is actually used, e.g. most content is in the SDR range, with specular highlights and bright details beyond the SDR range, in the HDR headroom.
This more closely matches how HDR is handled on Apple platforms, as EDR.
This also greatly simplifies application code which no longer has to think about color scaling. SDR content is rendered at the appropriate brightness automatically, and HDR content is scaled to the correct range for the display HDR headroom.
Sam Lantinga
Anonymous Maarten
Mark Delk
Frank Praznik
Pierre Wendling
Ivan Epifanov
Cameron Gutman
Petar Popovic
Mathieu Eyraud
rofl0r
Ryan C. Gordon
Ethan Lee
Semphris
Dimitriy Ryazantcev
Anthony
Riccardo Marcangelo
r4nx
Green Sky
Simon McVittie
Mingjie Shen
Susko3
Ozkan Sezer
Sylvain
meyraud705
Jade Macho
danginsburg
Dan Ginsburg
David Gow