According to #8088 it has no value as an automated test, and by
default it takes long enough to hit the default test timeout.
Resolves: #8088
Signed-off-by: Simon McVittie <smcv@collabora.com>
The current status is stored in the SDL_rwops 'status' field to be able to determine whether a 0 return value is caused by end of file, an error, or a non-blocking source not being ready.
The functions to read sized datatypes now return SDL_bool so you can detect read errors.
Fixes https://github.com/libsdl-org/SDL/issues/6729
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>
This slightly newer device than the one from #7814 is functionally
equivalent when connected via USB. When connected via Bluetooth, it has
a different button mapping.
Thanks to Sam Lantinga.
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://github.com/ValveSoftware/steam-devices/pull/34 lists several
more devices that are functionally equivalent to this one from the
point of view of their evdev metadata. Thanks to apgrc.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Also make details of PS4 gamepads (which are very similar from an evdev
point of view) more specific.
Thanks to Sam Lantinga and Jeremy Whiting for recording these.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Like the Stadia controller, this is unusual because it represents the
Share button as the Record key from a multimedia keyboard (as of Linux
6.2.11 with the xpad driver). Thanks to Jeremy Whiting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a bit unusual because it has a small number of what would
ordinarily be keyboard keys. Thanks to Jeremy Whiting for recording
this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A newer evemu-describe transcript has this same controller with its
buttons mapped differently, presumably a result of driver changes in
the Linux kernel. Either way, we should recognise it as a gamepad.
Thanks to Jeremy Whiting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This didn't include any buttons, which I assume was because I
transcribed them incorrectly rather than reflecting reality. Confirmed
against another Switch Pro Controller on a more recent kernel (thanks
to Jeremy Whiting).
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't need to re-test the heuristic with the same input data, but
knowing that another device has equivalent evdev metadata is useful
information to record. Thanks to Jeremy Whiting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was reported by Rémi Bernon as an example of older SDL's non-udev
code path going wrong for touchpads when the invoking user happens to
be in the input group, which I believe was fixed by fdd945f2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ideally we'd detect these as "joysticks" (or more generally, gaming
controllers), but in most cases their evdev flags are indistinguishable
from an accelerometer or gyro, so the only way to achieve this would be
a table of known devices that doesn't currently exist.
One exception is the one that reports a THROTTLE axis and TRIGGER, THUMB
buttons, which would be reasonable to detect via the joystick heuristic.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There are some devices for which SDL's device classification heuristic
is known not to give the ideal result. Add a way to incorporate these
into our test data, so that when the heuristic is improved we can
detect them as their intended device type, without making the test fail
before that has been implemented.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have gotten feedback that abstracting the coordinate system based on the display scale is unexpected and it is difficult to adapt existing applications to the proposed API.
The new approach is to provide the coordinate systems that people expect, but provide additional information that will help applications properly handle high DPI situations.
The concepts needed for high DPI support are documented in README-highdpi.md. An example of automatically adapting the content to display scale changes can be found in SDL_test_common.c, where auto_scale_content is checked.
Also, the SDL_WINDOW_ALLOW_HIGHDPI window flag has been replaced by the SDL_HINT_VIDEO_ENABLE_HIGH_PIXEL_DENSITY hint.
Fixes https://github.com/libsdl-org/SDL/issues/7709
Re-writes the clipboard data handling in wayland to an on demand
solution where callbacks are provided to generate/provide the clipboard
data when requested by the OS.
- SDL_AudioCVT is gone, even internally.
- libsamplerate is gone (I suspect our resampler is finally Good Enough).
- Cleanups and improvements to audio conversion interfaces.
- SDL_AudioStream can change its input/output format/rate/channels on the fly!
Ryan C. Gordon
Simon McVittie
Sam Lantinga
Brick
Ozkan Sezer
Frank Praznik
Anonymous Maarten
luzpaz
Sylvain
Linus Probert