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!
Otherwise they'll try to run with no arguments, and fail, when run by
ginsttest-runner.
Fixes: 81ca9d61 "cmake+test: add more automated tests + use properties"
Signed-off-by: Simon McVittie <smcv@collabora.com>
It turns out there's a race condition on X11 where the window could be placed by the window manager while being placed by the application, so we need to have the initial position available at window creation.
Anonymous Maarten
Sam Lantinga
Simon McVittie
luzpaz
Sylvain
Ozkan Sezer
Linus Probert
Brick
Ryan C. Gordon