Wayland can expose displays in any arbitrary order, and doesn't have the native concept of a primary display. However, there are games that presume that the first listed display is the primary, which can lead to problems if that output isn't necessarily the ideal one, as they may use that display to build a resolution list or as the default fullscreen output. This sorts displays by position, then attempts to find the primary display, first by querying the explicit ordering hint, then the GNOME DBus property, then tries to determine the 'best' display according to the criteria that is generally ideal for games and media playback.
The makes the list of displays deterministic, as long as the desktop configuration remains static, with a reasonably appropriate one prioritized as primary, even if there is no explicit way to retrieve the primary display. In the case where a user has a particularly esoteric physical display configuration, the new hint enables explicitly overriding the sorting and selection logic, allowing the entire display order to be customized, if necessary.
We require stdbool.h in the build environment, so we might as well use the plain bool type.
If your environment doesn't have stdbool.h, this simple replacement will suffice:
typedef signed char bool;
The flags parameter has been removed from SDL_CreateRenderer() and SDL_RENDERER_PRESENTVSYNC has been replaced with SDL_PROP_RENDERER_CREATE_PRESENT_VSYNC_NUMBER during window creation and SDL_PROP_RENDERER_VSYNC_NUMBER after renderer creation.
SDL_SetRenderVSync() now takes additional values besides 0 and 1.
The maximum texture size has been removed from SDL_RendererInfo, replaced with SDL_PROP_RENDERER_MAX_TEXTURE_SIZE_NUMBER.
The pointer confinement protocol does allow attempted warping the pointer via a hint, provided that the pointer is locked at the time of the request, and the requested coordinates fall within the bounds of the window.
Toggle the pointer locked state and request the pointer warp when the required protocol is available. This is similar to what XWayland does internally.
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.
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.
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
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.
