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.
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.
main features:
- No more sdl-build-options/sdl-shared-build-options/sdl-global-options
- Dependency information is stored on SDL3-collector for sdl3.pc
- Use helper functions to modify the SDL targets;
- sdl_sources to add sources
- sdl_glob_sources to add glob soruces
- sdl_link_dependency to add a link dependency that might also
appear in sdl3.pc/SDL3Config.cmake
- sdl_compile_definitions to add macro's
- sdl_compile_options for compile options
- sdl_include_directories for include directories
They avoid repeated checks for existence of the SDL targets
- A nice feature of the previous is the ability to generate
a sdl3.pc or SDL3Config.cmake that describes its dependencies
accurately.
various:
- remove duplicate libc symbol list
- add CheckVulkan
- remove unused HAVE_MPROTECT
- add checks for getpagesize
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.
The gamepad vs joystick events always happen in this order:
SDL_EVENT_JOYSTICK_ADDED
SDL_EVENT_GAMEPAD_ADDED
SDL_EVENT_GAMEPAD_REMAPPED
SDL_EVENT_GAMEPAD_REMOVED
SDL_EVENT_JOYSTICK_REMOVED
Whenever a mapping is changed, any controller affected by that mapping will generate a gamepad event. You will only get one SDL_EVENT_GAMEPAD_REMAPPED event per controller per batch of mapping changes, where SDL_AddGamepadMappingsFromFile() and SDL_AddGamepadMapping() are each a batch of changes.
Also renamed most cases of SDL_GAMEPAD_TYPE_UNKNOWN to SDL_GAMEPAD_TYPE_STANDARD, and SDL_GetGamepadType() will return SDL_GAMEPAD_TYPE_UNKNOWN only if the gamepad is invalid.
Removing SDL_GAMEPAD_TYPE_VIRTUAL allows a virtual controller to emulate another gamepad type. The other controller types can be treated as generic controllers by applications without special glyph or functionality treatment.
If a device is positively identified as an accelerometer, pointing stick
or clickpad, then we don't need to second-guess it.
In practice this does not change the result for any device in our
test data, so add some artificial records that exercise this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In newer kernels, devices that can be positively identified as a
particular device type (for example accelerometers) get a property
bit set. Plumb this information through into the function, but don't
use it for anything just yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The props array was too small for the highest property bits to be set,
although in practice this didn't matter since only the lower-order bits
have a meaning. Make it consistent with all the others.
Signed-off-by: Simon McVittie <smcv@collabora.com>
udev distinguishes between ID_INPUT_KEY, a device with any keyboard keys
at all (including for example USB numeric keypads, Bluetooth headsets
with volume control buttons, and some game controllers; and
ID_INPUT_KEYBOARD, a reasonably fully-featured keyboard that you could
use for general-purpose text entry. If we do the same here, then it's
useful input to our heuristics for identifying devices: for example,
a device with ID_INPUT_KEY could reasonably be a gamepad, but a device
with ID_INPUT_KEYBOARD certainly isn't.
Resolves: https://github.com/libsdl-org/SDL/issues/7827
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't currently use these for anything, but we might start using
them as input to our heuristics as part of #7697.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't currently use these in our device-classification heuristic,
but it could be a useful input in future.
Thanks to Sam Lantinga, Ben Fradella, kevenwyld and schlegp for
providing some of these.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The comments here disagreed with the actual bytes. According to
https://elixir.bootlin.com/linux/v6.3.7/source/drivers/hid/hid-wiimote-modules.c,
the Balance Board reports BTN_A and ABS_HAT0X, HAT0Y, HAT1X and HAT1Y.
This means the comments here were correct, but the .abs bits shown
were in the wrong byte.
Matching the Wii U Pro Controller against the same kernel source, it
appears to be correct: it's the same representation as a PS3 gamepad,
except that it lacks the Z and RZ axes for analogue triggers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of the test data previously seen here was guessed from kernel
source code, and not all of it was correct. The following devices have
now been verified against `evemu-describe` output with Linux 6.3
(thanks to Jeremy Whiting for collecting this):
- basic Wiimote
- buttons
- 3-axis accelerometer
- infra-red sensor for Sensor Bar location (precise aim)
- Motion Plus accessory (3-axis gyroscope)
- Nunchuck accessory (joystick, 2 buttons, second 3-axis accelerometer)
- Classic Controller accessory (a complete traditional gamepad)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ryan C. Gordon
Ozkan Sezer
Frank Praznik
Sam Lantinga
Anonymous Maarten
Simon McVittie
luzpaz
Sylvain