This can be used to work around issues where the Apple GCController driver doesn't work for some controllers but there's no way to know which GCController maps to which IOKit device.
This patch adds an API for querying pressure-
sensitive pens, cf. SDL_pen.h:
- Enumerate all pens
- Get pen capabilities, names, GUIDs
- Distinguishes pens and erasers
- Distinguish attached and detached pens
- Pressure and tilt support
- Rotation, distance, throttle wheel support
(throttle wheel untested)
- Pen type and meta-information reporting
(partially tested)
Pen event reporting:
- Three new event structures: PenTip, PenMotion, and
PenButton
- Report location with sub-pixel precision
- Include axis and button status, is-eraser flag
Internal pen tracker, intended to be independent
of platform APIs, cf. SDL_pen_c.h:
- Track known pens
- Handle pen hotplugging
Automatic test:
- testautomation_pen.c
Other features:
- XInput2 implementation, incl. hotplugging
- Wayland implementation, incl. hotplugging
- Backward compatibility: pen events default to
emulating pens with mouse ID SDL_PEN_MOUSEID
- Can be toggled via SDL_HINT_PEN_NOT_MOUSE
- Test/demo program (testpen)
- Wacom pen feature identification by pen ID
Acknowledgements:
- Ping Cheng (Wacom) provided extensive feedback
on Wacom pen features and detection so that
hopefully untested Wacom devices have a
realistic chance of working out of the box.
This gives applications and binding systems a clearer view of what the hardware is so they can make intelligent decisions about how to present things to the user.
Gamepad mappings continue to use abxy for the face buttons for simplicity and compatibility with earlier versions of SDL, however the "SDL_GAMECONTROLLER_USE_BUTTON_LABELS" hint no longer has any effect.
Fixes https://github.com/libsdl-org/SDL/issues/6117
These were added a very long time ago and seem to serve no purpose now, as the functionality they provided is now in core Wayland protocols, current information on their usage and status is nonexistent, no modern compositor seems to support them, and the code paths are untested and subject to bit-rot at this point. It also causes duplicate symbol issues when statically linking an application to both Qt and SDL.
XINPUT_STATE_EX isn't actually a thing, we can just use the normal XINPUT_STATE
Fixes https://github.com/libsdl-org/SDL/issues/2797
(cherry picked from commit e8f4045d0bccacbf8f4b716d0dde17140e9f2cc4)
SDL_PollEvent(), SDL_WaitEvent(), and SDL_WaitEventTimeout() all return SDL_bool.
SDL_AddEventWatch() returns an int result code.
Also improved timeout accuracy in SDL_WaitEventTimeout()
This lets apps optionally have a handful of callbacks for their entry points instead of a single main function. If used, the actual main/SDL_main/whatever entry point will be implemented in the single-header library SDL_main.h and the app will implement four separate functions:
First:
int SDL_AppInit(int argc, char **argv);
This will be called once before anything else. argc/argv work like they always do. If this returns 0, the app runs. If it returns < 0, the app calls SDL_AppQuit and terminates with an exit code that reports an error to the platform. If it returns > 0, the app calls SDL_AppQuit and terminates with an exit code that reports success to the platform. This function should not go into an infinite mainloop; it should do any one-time startup it requires and then return.
Then:
int SDL_AppIterate(void);
This is called over and over, possibly at the refresh rate of the display or some other metric that the platform dictates. This is where the heart of your app runs. It should return as quickly as reasonably possible, but it's not a "run one memcpy and that's all the time you have" sort of thing. The app should do any game updates, and render a frame of video. If it returns < 0, SDL will call SDL_AppQuit and terminate the process with an exit code that reports an error to the platform. If it returns > 0, the app calls SDL_AppQuit and terminates with an exit code that reports success to the platform. If it returns 0, then SDL_AppIterate will be called again at some regular frequency. The platform may choose to run this more or less (perhaps less in the background, etc), or it might just call this function in a loop as fast as possible. You do not check the event queue in this function (SDL_AppEvent exists for that).
Next:
int SDL_AppEvent(const SDL_Event *event);
This will be called once for each event pushed into the SDL queue. This may be called from any thread, and possibly in parallel to SDL_AppIterate. The fields in event do not need to be free'd (as you would normally need to do for SDL_EVENT_DROP_FILE, etc), and your app should not call SDL_PollEvent, SDL_PumpEvent, etc, as SDL will manage this for you. Return values are the same as from SDL_AppIterate(), so you can terminate in response to SDL_EVENT_QUIT, etc.
Finally:
void SDL_AppQuit(void);
This is called once before terminating the app--assuming the app isn't being forcibly killed or crashed--as a last chance to clean up. After this returns, SDL will call SDL_Quit so the app doesn't have to (but it's safe for the app to call it, too). Process termination proceeds as if the app returned normally from main(), so atexit handles will run, if your platform supports that.
The app does not implement SDL_main if using this. To turn this on, define SDL_MAIN_USE_CALLBACKS before including SDL_main.h. Defines like SDL_MAIN_HANDLED and SDL_MAIN_NOIMPL are also respected for callbacks, if the app wants to do some sort of magic main implementation thing.
In theory, on most platforms these can be implemented in the app itself, but this saves some #ifdefs in the app and lets everyone struggle less against some platforms, and might be more efficient in the long run, too.
On some platforms, it's possible this is the only reasonable way to go, but we haven't actually hit one that 100% requires it yet (but we will, if we want to write a RetroArch backend, for example).
Using the callback entry points works on every platform, because on platforms that don't require them, we can fake them with a simple loop in an internal implementation of the usual SDL_main.
The primary way we expect people to write SDL apps is with SDL_main, and this is not intended to replace it. If the app chooses to use this, it just removes some platform-specific details they might have to otherwise manage, and maybe removes a barrier to entry on some future platform.
Fixes#6785.
Reference PR #8247.
Almost nothing checks these return values, and there's no reason a valid
lock should fail to operate. The cases where a lock isn't valid (it's a
bogus pointer, it was previously destroyed, a thread is unlocking a lock it
doesn't own, etc) are undefined behavior and always were, and should be
treated as an application bug.
Reference Issue #8096.
It needs to be SDL_RELEASE_GENERIC, because it releases both exclusive
(writer) and shared (reader) locks.
Without this fix, clang's `-Wthread-safety` tests generate incorrect warnings.
Reference Issue #8096.
The following objects now have properties that can be user modified:
* SDL_AudioStream
* SDL_Gamepad
* SDL_Joystick
* SDL_RWops
* SDL_Renderer
* SDL_Sensor
* SDL_Surface
* SDL_Texture
* SDL_Window
Also switched the D3D11 and D3D12 renderers to use real NV12 textures for NV12 data.
The combination of these two changes allows us to implement 0-copy video decode and playback for D3D11 in testffmpeg without any access to the renderer internals.
Whenever I have to fix something endianness-related, I always get
confused about whether the byte-oriented format that guarantees to put
red in byte 0 is RGBA8888 or RGBA32. (The answer is that it's RGBA32.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is essentially the same as was added in d95d2d70, but with clearer
error handling. It's implemented in a private header file so that it
can be shared with SDL_shape, which also wants this functionality.
Resolves: https://github.com/libsdl-org/SDL/issues/8319
Signed-off-by: Simon McVittie <smcv@collabora.com>
This fires if an opened device changes formats (which it can on Windows,
if the user changes this in the system control panel, and WASAPI can
report), or if a default device migrates to new hardware and the format
doesn't match.
This will fire for all logical devices on a physical device (and if it's
a format change and not a default device change, it'll fire for the
physical device too, but that's honestly not that useful and might change).
Fixes#8267.
Now it offers the total requested bytes in addition to the amount
immediately needed (and immediately needed might be zero if the stream
already has enough queued to satisfy the request.
You can see it in action in testaudio by mousing over a logical device; it
will show a visualizer for the current PCM (whatever is currently being
recorded on a capture device, or whatever is being mixed for output on
playback devices).
Fixes#8122.
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).
This is meant to offer a simplified API for people that are either migrating
directly from SDL2 with minimal effort or just want to make noise without
any of the fancy new API features.
Users of this API can just deal with a single SDL_AudioStream as their only
object/handle into the audio subsystem.
They are still allowed to open multiple devices (or open the same device
multiple times), but cannot change stream bindings on logical devices opened
through this function.
Destroying the single audio stream will also close the logical device behind
the scenes.
SDL considers a hidden window to be unmapped and blocks or defers certain operations until the window is shown again, however, the X11 and Cocoa backends would set the hidden flag when the window was minimized, which blocked the functionality of SDL_RestoreWindow().
Specify that a window with the hidden flag set is unmapped and not visible on the desktop or in the dock/taskbar without a call to SDL_ShowWindow(), and don't set the hidden flag in the X11 and Cocoa backends when the window is in the minimized state, but still mapped to the desktop.
CMake's SDL_build_config.h force disables HAVE_STDIO_H when buiding
winrt in non-libc mode.
Becase CreateFileEx is not available in UWP mode, use CreateFile2
instead.
The sequence order of the four paddles is not obvious, with SDL and Xbox
controllers swapping the order of P2 and P3 relative to each other.
If we group them into left and right, then it becomes more obvious.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The current status is stored in the SDL_rwops 'status' field to be able to determine whether a 0 return value is caused by end of file, an error, or a non-blocking source not being ready.
The functions to read sized datatypes now return SDL_bool so you can detect read errors.
Fixes https://github.com/libsdl-org/SDL/issues/6729
Add SDL_ShowWindowSystemMenu() to display the system-level menu for windows. Typically, this is done by right-clicking on the system provided window decorations, however, if an application is rendering its own client-side decorations, there is currently no way to display it. This menu is provided by the system and can provide privileged desktop functionality such as moving or pinning a window to a specific workspace or display, setting the always-on-top property, or taking screenshots. In many cases, there are no APIs which allow applications to perform these actions manually.
Implemented for Wayland via functionality provided by the xdg_toplevel protocol, Win32 via the undocumented message 0x313 (typically called WM_POPUPSYSTEMMENU), and X11 via the "_GTK_SHOW_WINDOW_MENU" atom (supported in GNOME and KDE).
This rips up the entire SDL audio subsystem! While we still feed the audio device from a separate thread, the audio callback into the app is now gone a totally optional alternative.
Now the app will bind an SDL_AudioStream to a given device and feed data to it. As many streams as one likes can be bound to a device; SDL will mix them all into a single buffer and feed the device from there.
So not only does this function as a basic mixer, it also means that multiple device opens are handled seamlessly (so if you want to open the device for your game, but you also link to a library that provides VoIP and it wants to open the device separately, you don't have to worry about stepping on each other, or that the OS will fail to allow multiple opens of the same device, etc).
Merged from pull request #7704.
Fixes#7379.
Reference Issue #6889.
Reference Issue #6632.
Render targets are a core feature of SDL 3.0, so this flag has been removed.
The OpenGL ES renderer still doesn't support them, but we'll deal with that later.
Fixes https://github.com/libsdl-org/SDL/issues/8059
Now you open an audio device and attach streams, as planned, but each
open generates a new logical device. Each logical device has its own
streams that are managed as a group, but all streams on all logical
devices are mixed into a single buffer for a single OS-level open of
the physical device.
This allows multiple opens of a device that won't interfere with each
other and also clean up just what the opener assigned to their logical
device, so all their streams will go away on close but other opens will
continue to mix as they were.
More or less, this makes things work as expected at the app level, but
also gives them the power to group audio streams, and (once added) pause
them all at once, etc.
main features:
- No more sdl-build-options/sdl-shared-build-options/sdl-global-options
- Dependency information is stored on SDL3-collector for sdl3.pc
- Use helper functions to modify the SDL targets;
- sdl_sources to add sources
- sdl_glob_sources to add glob soruces
- sdl_link_dependency to add a link dependency that might also
appear in sdl3.pc/SDL3Config.cmake
- sdl_compile_definitions to add macro's
- sdl_compile_options for compile options
- sdl_include_directories for include directories
They avoid repeated checks for existence of the SDL targets
- A nice feature of the previous is the ability to generate
a sdl3.pc or SDL3Config.cmake that describes its dependencies
accurately.
various:
- remove duplicate libc symbol list
- add CheckVulkan
- remove unused HAVE_MPROTECT
- add checks for getpagesize
Adds the SDL_EVENT_WINDOW_OCCLUDED events and the window flag SDL_WINDOW_OCCLUDED to report when the window occlusion state has changed, so that the application can take appropriate measures, as it may wish to suspend drawing, throttle, or otherwise behave in a more energy efficient manner when the window is not visible. When the window is no longer occluded, the SDL_EVENT_WINDOW_EXPOSED event is sent and the occlusion flag is cleared.
This is handled on macOS via the window occlusion state event (available as of 10.9), and via the xdg-shell protocol on Wayland (version 6, wayland-protocols 1.32, passed through in libdecor 0.1.2).
Also renamed most cases of SDL_GAMEPAD_TYPE_UNKNOWN to SDL_GAMEPAD_TYPE_STANDARD, and SDL_GetGamepadType() will return SDL_GAMEPAD_TYPE_UNKNOWN only if the gamepad is invalid.
Removing SDL_GAMEPAD_TYPE_VIRTUAL allows a virtual controller to emulate another gamepad type. The other controller types can be treated as generic controllers by applications without special glyph or functionality treatment.
This will simplify the X11 and Wayland implementations, which were doing that under the hood, and makes application interaction between the two APIs consistent.
The destination rectangle passed to SDL_BlitSurface() and SDL_BlitSurfaceScaled() is non-const and filled in with the final destination rectangle after clipping, and now documented as such.
Fixes https://github.com/libsdl-org/SDL/issues/7911