Send keyboard and mouse added/removed events when seat capabilities change. Note that Wayland only supports one global keyboard and mouse object per seat, so events coming from different keyboards and mice on the same seat can't be distinguished.
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.
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.
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.
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.
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.
