These files are completely different from SDL2, and no clean merging
is likely to happen there anyhow, so there's really no harm in just
switching them over completely to SDL3's new policy of allowing `//`
comments and mixed variable declarations.
Feels deeply sacrilegious, though.
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.
I don't think this can fail at the moment, but if WaveCheckFormat goes
out of sync with this switch statement at some point, this seems like
a good failsafe.
This adds support for the back paddles, and the "..." key
which are not automatically detected.
* "Back" is mapped to the top left "two windows" key.
* "Start" is mapped to the top right "hambuger menu" key.
* "Guide" is mapped to the "Steam" key.
* The "..." key is just a generic button.
When looking at the screen, paddles are number
* P1: Top right
* P2: Top left
* P3: Bottom right
* P4: Botom Left
The new controller mapping was created with the SDL3 gamepadmap tool.
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.
This call is actually a left-over when porting from fcitx4 service to the new org.freedesktop.portal.Fcitx supported by both fcitx4/fcitx5. CloseIC is actually never a part of the new interface on org.freedesktop.portal.Fcitx. It cause any issue user visible effect.
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.
Ryan C. Gordon
1vanK
Mathieu Eyraud
Ozkan Sezer
Anonymous Maarten
SDL Wiki Bot
Sam Lantinga
Max Maisel
Frank Praznik
Starbuck5
Alexander Richards
Weng Xuetian