Zombie devices just sit there doing nothing until a new default device
is chosen, and then they migrate all their logical devices before being
destroyed.
This lets the system deal with the likely outcome of a USB headset being
the default audio device, and when its cable is yanked out, the backend
will likely announce this _before_ it chooses a new default (or, perhaps,
the only device in the system got yanked out and there _isn't_ a new
default to be had until the user plugs the cable back in).
This lets the audio device hold on without disturbing the app until it can
seamlessly migrate audio, and it also means the backend does not have to
be careful in how it announces device events, since SDL will manage the
time between a device loss and its replacement.
Note that this _only_ applies to things opened as the default device
(SDL_AUDIO_DEVICE_DEFAULT_OUTPUT, etc). If those USB headphones are the
default, and one SDL_OpenAudioDevice() call asked for them specifically and
the other just said "give me the system default," the explicitly requested
open will get a device-lost notification immediately. The other open will
live on as a zombie until it can migrate to the new default.
This drops the complexity of the PulseAudio hotplug thread dramatically,
back to what it was previously, since it no longer needs to fight against
Pulse's asychronous nature, but just report device disconnects and new
default choices as they arrive.
loopwave has been updated to not check for device removals anymore; since
it opens the default device, this is now managed for it; it no longer
needs to close and reopen a device, and as far as it knows, the device
is never lost in the first place.
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.
