libdecor can send a size of zero as a valid value, the use of which will close the window. Make sure the minimum width/height are clamped to a minimum of 1.
The usable fullscreen bounds need to be queried after window creation, as Wayland can send different usable bounds depending on the focused window's scaling mode.
Add a mode that forces Wayland windows to output with scaling that forces 1:1 pixel mapping.
This is intended to allow legacy applications to be displayed without desktop scaling being applied, and may have issues with some display configurations, as this forces the window to behave in a way that Wayland desktops were not designed to accommodate (rounding errors can result from certain combinations of window/scale values, the window may be unusably small, jump in size at times, or appear to be larger than the desktop space, and cursor precision may be reduced).
Windows flagged as DPI-aware are not affected by this.
The automated video test suite passes with the hint turned on.
KDE provides the kde_output_order_v1 protocol, which tells clients the preferred order of all connected displays. Sort SDL displays according to the provided list at init time.
GNOME can deliver displays in arbitrary order, which can even change across sleep/wake cycles, so use a DBus method to find the primary display, and try to make sure it is the first exposed by SDL.
On other window managers, continue to assume that the order in which displays are exposed is the preferred order.
This can eventually be replaced by a Wayland protocol that serves the same purpose, if the pending ones are ever finalized.
Fixes a crash if no seat was available at initialization, but still allows for one to still be created later if an input device is added.
Removes some unnecessary abstractions in the process.
Distinguish between and handle fullscreen window moves initiated by the window manager vs the application to avoid cases where the window snaps back to the original display when moved due to the use of old coordinates.
Add the ability to import and wrap external surfaces from external toolkits such as Qt and GTK.
Wayland surfaces and windows are more intrinsically tied to the client library than other windowing systems, so it is necessary to provide a way to initialize SDL with an existing wl_display object, which needs to be set prior to video system initialization, or export the internal SDL wl_display object for use by external applications or toolkits. For this, the global property SDL_PROPERTY_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER is used.
A Wayland example was added to testnative, and a basic example of Qt 6 interoperation is provided in the Wayland readme to demonstrate the use of external windows with both SDL owning the wl_display, and an external toolkit owning it.
Windows doesn't inform applications if the window is in the docked/tiled state, so let windows manage the window size when restoring from a fixed-size state, unless the application explicitly requested a new size/position.
Fixes the video_getSetWindowState test.
WM_WINDOWPOSCHANGING needs to return 0 when a resize was initiated programmatically
Checking the SWP_NOMOVE and SWP_NOSIZE flags in the WINDOWPOS struct when handling WM_WINDOWPOSCHANGED to avoid sending redundant resize and move events is unreliable, as they can be set even when the window has moved or changed size, such as when leaving fullscreen, or programmatically resizing a window without STYLE_RESIZABLE set.
Fixes the video_getSetWindowSize and video_setWindowCenteredOnDisplay tests.
Allow for the creation of SDL windows with a roleless surface that applications can use for their own purposes, such as with a windowing protocol other than XDG toplevel.
The property `wayland.surface_role_custom` will create a window with a surface that SDL can render to and handles input for, but is not associated with a toplevel window, so applications can use it for their own, custom purposes (e.g. wlr_layer_shell).
A test/minimal example is included in tests/testwaylandcustom.c
A Wayland registry object can only have one listener attached at a time, so an application attempting to use the backend SDL registry object for its own purposes will just result in an error. Remove this property, as it is of no use to applications and will only result in errors.
If an application needs the registry, it needs to get the wl_display object via `SDL.window.wayland.display` and use wl_display_get_registry() to create a new registry object that it can attach its own listeners to.
If the xdg_wm_base protocol isn't present, the window won't be assigned a valid surface type at creation time, which makes these checks redundant.
The libdecor path was already cleaned up in this manner some time ago.
Wayland will be increasingly encountered going forward and needs to be handled by applications requesting window handles to initialize the Vulkan WSI and such, so include it in the migration example to reflect current best practices.
For some reason, fullscreen space windows won't get any mouse button events unless the NSWindowStyleMaskTitled flag is set when entering fullscreen, even though they successfully become key and receive mouse motion events. Make sure the flag is always set when entering fullscreen space state.
Send fullscreen enter/leave events, which will implicitly update the fullscreen flag. Manually setting the flag will suppress attempts to send the events later, as the flag is used for deduplication purposes in the event code.
Don't mark fullscreen windows as having a title bar if the window is borderless, or it can end up in a weird, pseudo-decorated state when leaving fullscreen if the borders were toggled back on while the window was fullscreen.
Setting the window styling when about to leave fullscreen caused issues with this as well and is no longer needed, as it is ensured that the window's resizable state won't change while in a fullscreen space, or in a transition period.
Don't check the fullscreen flag when toggling resizable, bordered, always on top, minimum size and maximum size, as the flag doesn't reflect pending async changes that may be in progress.
These properties can be made to be safely toggled while the window is in fullscreen mode and applied when returning to windowed mode, which ensures that requested window settings aren't lost if calling these functions while async fullscreen changes are in flight.
Account for the border sizes when restoring the window and only turn off resize events when entering or leaving fullscreen until the frame extents are changed, and only if they are, or previously were, non-zero.
This necessitated further refinement to the sync algorithm as well, but as a result, the sync function no longer occasionally times out if creating a window and immediately recreating it when initializing a renderer, and some rare, spurious size and position failures in the centered window and state automated tests seem to be fixed.
Compositors may switch from mouse to touch mode when a touch event is received, causing a pointer leave event and subsequent loss of mouse focus.
Don't relinquish mouse focus on surfaces with active touch events. If there are active touch events when pointer focus is lost, the keyboard focus is used as a fallback for relinquishing mouse focus: if, in this case, the keyboard focus is then lost and there are no active touches, mouse focus is lost, and if all touches are raised and there is no keyboard or pointer focus, then the window loses mouse focus.
Track and check move and resize requests separately, and consider them done if either the window is already at the expected location, or at least one configure event which moved or resized the window was processed. The avoids a timeout condition if resizing the window caused it to be implicitly moved in order to keep it within desktop bounds.
The automated positioning test now runs on GNOME/X11 without any sync requests timing out.
SDL window size, state, and position functions have been considered immediate, with their effects assuming to have taken effect upon successful return of the function. However, several windowing systems handle these requests asynchronously, resulting in the functions blocking until the changes have taken effect, potentially for long periods of time. Additionally, some windowing systems treat these as requests, and can potentially deny or fulfill the request in a manner differently than the application expects, such as not allowing a window to be positioned or sized beyond desktop borders, prohibiting fullscreen, and so on.
With these changes, applications can make requests of the window manager that do not block, with the understanding that an associated event will be sent if the request is fulfilled. Currently, size, position, maximize, minimize, and fullscreen calls are handled as asynchronous requests, with events being returned if the request is honored. If the application requires that the change take effect immediately, it can call the new SDL_SyncWindow function, which will attempt to block until the request is fulfilled, or some arbitrary timeout period elapses, the duration of which depends not only on the windowing system, but on the operation requested as well (e.g. a 100ms timeout is fine for most X11 events, but maximizing a window can take considerably longer for some reason). There is also a new hint 'SDL_VIDEO_SYNC_ALL_WINDOW_OPS' that will mimic the old behavior by synchronizing after every window operation with, again, the understanding that using this may result in the associated calls blocking for a relatively long period.
The deferred model also results in the window size and position getters not reporting false coordinates anymore, as they only forward what the window manager reports vs allowing applications to set arbitrary values, and fullscreen enter/leave events that were initiated via the window manager update the window state appropriately, where they didn't before.
Care was taken to ensure that order of operations is maintained, and that requests are not ignored or dropped. This does require some implicit internal synchronization in the various backends if many requests are made in a short period, as some state and behavior depends on other bits of state that need to be known at that particular point in time, but this isn't something that typical applications will hit, unless they are sending a lot of window state in a short time as the tests do.
The automated tests developed to test the previous behavior also resulted in previously undefined behavior being defined and normalized across platforms, particularly when it comes to the sizing and positioning of windows when they are in a fixed-size state, such as maximized or fullscreen. Size and position requests made when the window is not in a movable or resizable state will be deferred until it can be applied, so no requests are lost. These changes fix another long-standing issue with renderers recreating maximized windows, where the original non-maximized size was lost, resulting in the window being restored to the wrong size. All automated video tests pass across all platforms.
Overall, the "make a request/get an event" model better reflects how most windowing systems work, and some backends avoid spending significant time blocking while waiting for operations to complete.
The hash table can be recursively locked from the same thread, which can cause issues with RWLocks, as locking them recursively can result in undefined behavior or deadlocks. Use a mutex instead, as it can be safely recursively locked.
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.
If the done signal is emitted by the common event handler, the window and all of its children have already been destroyed, so don't try to render with invalid renderer objects.
Pointers to static internal data need to be updated when copying events, or the cleanup code will attempt to free old stack data that went out of scope.
ALSA expects handles to be of type ALSA_Device, and passing the handle for the default device as a plain string causes a crash as it attempts to deference the string contents itself as a pointer to a string.
Create immutable static ALSA_Device structs for the default devices and pass those as the handles. They are not placed in the hotplug list, and the audio layer doesn't attempt to free ALSA handles, so there is no need to worry about them being erroneously freed.
The primary selection protocol is optional, so the function pointers to the internal Wayland functions should only be set if the protocol is supported. This allows graceful fall-back to the generic SDL implementation in other cases.
Fixes the clipboard tests under Weston.
When initializing the Wayland driver, check if the application is being started in, or trying to connect to, a Wayland session and skip to another driver if not. If neither WAYLAND_DISPLAY nor XDG_SESSION_TYPE are set, try to start anyway, and if the Wayland library is missing or no Wayland sessions are started, initialization will fail later in the process as it previously did.
This fixes the case where a Wayland session is running on a different VT, but an application wishes to run via KMSDRM on the current VT.
Querying the drag offer with every pointer movement would require refactoring to work with the portal implementation, however, there is little point, as the event layer just discards the file name. Remove the existing code and note that a new implementation is needed if the name ever starts to be passed though.
In the event that this is reimplemented, it should cache the filenames, as otherwise, this could potentially hammer the DBus interface hundreds or even thousands of times per second.
Libdecor creates subsurfaces of the primary SDL surface, but events from these surfaces should be ignored, or applications will get drag & drop events when dragged over drop shadows and such.
If a compositor tries to change the decoration mode when initially creating a window, the hidden flag might not yet be unset if the decoration mode is changed during the initial roundtrip in Wayland_ShowWindow(). As hiding the window destroys the decoration manager object, the hidden flag check is unnecessary, as the decoration configuration listener will never be entered when the window is hidden.
Wayland doesn't support programmatically setting the app icon, so note this restriction and specify that a desktop entry file that points to the desired icon image is required.
The default cursor was being leaked on destruction as it is not in the cursor list, and subsequently SDL_DestroyCursor() wouldn't call the free function for it.
The video core applies pending minimized/maximized/restored state to windows when they transition from the hidden to shown state, so no need to handle it internally anymore.
The 'orderOut' method has no effect on miniaturized windows, so 'close' must be used to remove the window from the desktop, dock, and window list in this case.
SDL holds a strong reference to the window (oneShot/releasedWhenClosed are 'NO'), and calling 'close' doesn't send a 'windowShouldClose' message, so it's safe to use for this purpose as nothing is implicitly released.
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.
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).
The mouse->CreateCursor function pointer will always be null if checked before the video backend is initialized, so a dummy default cursor with null internal structures was being created in all cases, not just for backends lacking cursor functionality. Move the check to after the video subsystem is initialized, when the function pointer check is valid.
Passing this dummy cursor with null internal structures to the Wayland backend would cause a crash, as it requires the internal cursor structures to be valid in order to store cursor backing data, even for default system cursors.
When using the Wayland video driver or X11 under XWayland, create a renderer and present a frame as part of window creation, as Wayland requires that a frame be presented for the window to be fully mapped and displayed onscreen. This fixes the grab and expected window size tests.
This also disables the window positioning tests when running under the Wayland driver, as Wayland does not allow application windows to position themselves in the desktop space, which renders the tests unreliable and subject to spurious failure.
In the event that the compositor sends window dimensions of (0,0), use the last requested compositor dimensions for fullscreen windows as opposed to trying to guess the target dimensions from the output, which can be null if no outputs are present, or wrong in the case of multi-display setups. Fullscreen windows must respect the maximum dimensions reported by the compositor, or a protocol violation can result.
This also prevents possible crashes if the compositor sends a config event with dimensions of (0,0) before a display has been added and/or finalized.
Add the flag "--suspend-when-occluded" to testgl, testgles2, and testsprite, which, when used, will suspend rendering and throttle the event loop when the occlusion flag is set on the window.
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).
The xdg_activation token requires specifying the surface that is the source of the activation request, not the surface of the target window. Setting this to the target window was causing raise requests to be blocked by the compositor, as if the surface noted as the origin of the request didn't currently have focus, it appeared to the compositor as though it was trying to 'steal' focus.
Use the implicit grab serial, which includes keyboard key, mouse button, touch, and tablet tool events, for setting the clipboard and primary selection data, as these are all considered valid originating event serials.
Add a DBus message handler to watch and respond to changes to the system cursor size and theme properties. Upon these settings being changed, a cursor refresh will be triggered so the new changes will take effect immediately, without the cursor having to leave and re-enter the window surface.
Applications that don't specify a rendering flag are likely handling Vulkan/GL themselves, so SDL loading OpenGL by default in this case is unnecessary overhead, and if a render backend requires it, the window will be recreated with the appropriate flags when the renderer is initialized.
Hiding a window and then clearing the minimized, maximized, fullscreen, or grabbed flags wouldn't result in the new state being applied to the window when shown, as the pending flags would always be zero, resulting in the flag application function never being entered. Calling SDL_RestoreWindow() didn't result in the minimized or maximized state being cleared on the hidden window either.
Save the current window flags to the pending flags when hiding a window, and universally apply the pending flags when the window is shown again to ensure that all state that was set or cleared when the window was hidden is applied. Any pending flags that match the existing window flags will be automatically deduplicated by the corresponding functions.
Add aspect-correct output of scaled video modes and a hint to control this behavior (aspect, stretch, or none).
The Wayland spec states that fullscreen surfaces that do not cover the entire output shall be centered with the borders masked by the compositor, so no additional work is required aside from calculating the proper window dimensions.
The default is still 'stretch' mode, as some window managers as of this time (KDE and older versions of GNOME still found in LTS distros) don't behave according to the spec and present an unmasked window that is not centered, so it's not yet safe to change the default.
Consolidate the X11_WMCLASS and WAYLAND_WMCLASS envvars into one SDL_HINT_APP_ID hint. This hint serves the same purpose on both windowing systems to allow desktop compositors to identify and group windows together, as well as associate applications with their desktop settings and icons.
The common code for retrieving the value is now consolidated under core/unix/SDL_appid.c as it's common to *nix platforms, and the value is now retrieved at window creation time instead of being cached by the video driver at startup so that changes to the hint after video initialization and before window creation will be seen, as well as to accommodate cases where applications want to use different values for different windows.
Ensure that incoming touch events originate from valid surfaces owned by SDL and have proper window data before forwarding them to the touch subsystem, or the window focus pointer that is sent with the event may not be a pointer to an SDL window.
Additionally, ensure that allocated touch events are always cleaned up on exit.
If the text-scaling-factor setting is available via D-Bus, add a listener and update the content scale values for the displays if the value is changed during runtime.
Factors out the D-Bus message pump from the system theme detection code to the general D-Bus code, as it's now used for more purposes than just the system theme.
Expose the text scaling factor (aka the global scale factor on KDE) as the display content scale value so applications can scale themselves as necessary.
If D-Bus is unavailable or retrieving the setting fails, fall back to trying the legacy GDK_SCALE envvar before reverting to the default 1.0 value.
Wayland doesn't support getting the true global cursor position, but it can be faked well enough for what most applications use it for: querying the global cursor coordinates and transforming them to the window-relative coordinates manually.
The global position is derived by taking the cursor position relative to the toplevel window, and offsetting it by the origin of the output the window is currently considered to be on. The cursor position and button state when the cursor is outside an application window are unknown, but this gives 'correct' coordinates when the window has focus, which is good enough for most applications.
If the popup is positioned such that it requires correction on both the x and y axes, it will be aligned with parent only at the window corners, which is neither overlapping nor adjacent. In this case, nudge the window plus or minus one screen unit on the x axis so it is properly adjacent to the parent and within spec guidelines.
Frank Praznik