This prevents an assertion whem LINUX_JoystickGetGamepadMapping tried to
open the stick temporarily and messed with global state by doing so. Now
the global state is only set in LINUX_JoystickOpen, but the common code
is shared by both interfaces.
Fixes#4198.
At least on bluetooth the guid user the version reported by the
bluetooth device. Which for Atari vcs controllers is the firmware
version. However the mapping will stay the same regardless of firmware
version, so ignore the version entirely to avoid needing a new mapping
entry for each firmware version.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
The information whether a specific joystick can be used as a gamepad is
not going to change every frame, so we can cache the result into a
variable.
This dramatically reduces the performance impact of SDL2 on small
embedded devices, since the code path that is now avoided was quite
heavy.
Fixes#4229.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
If we are running in a container, like Flatpak[1] or pressure-vessel[2],
it's likely that we are using user namespaces,
therefore udev event notification via netlink won't work reliably.
Use their filesystem API to detect them and automatically fallback to
the inotify-based enumeration.
[1] <https://flatpak.org/>
[2]
<https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/master/pressure-vessel>
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
pj5085
I added some printf to verify the math being done. Of the three joysticks I have, it works correctly for at least two, and seems to work correctly for the third. I say "seems to" because, for the third joystick, the values never go through the AxisCorrect function, and thus never hit my printf statements, even though they did in the version I wrote my patch against. I'm not sure what's going on there, but it at least seems to be working correctly in as much as I can tell.
I note this result in particular, for an SNES Gamepad (min=0, max=255):
Joystick value 0 becomes -32768
Joystick value 127 becomes 0
Joystick value 255 becomes 32767
Without the code that forces a zero point, the 127 input value would become -129, so I think you see why I added that code to turn it into zero. However, I think Kai Krakow has a point about how SDL shouldn't assume that there should be a center.
Obviously in the majority of cases there actually should be a center, and the code that turns that 127 into an actual 0 is creating only a 0.2% error over 0.4% of this joystick's range. However, what if there is an axis that is some kind of special control, like a 4-position switch, and, for whatever reason, the joystick reports it as an axis with 4 possible values, 0 to 3? In that case, mutilating the two center values to the same value is much more of an error and and turns that 4-position switch into a 3-position switch. If any joystick does this with a 2-position switch, then this code would render that control entirely useless as it would report the same value with the switch in either position. Obviously the code could require that there be at least N possible values, to guess whether something is a proper axis or just some kind of switch, but the choice of N would be arbitrary and that's ugly.
I guess the real problem here is that my gamepad is just kind of broken. It should be reporting a range of -1 to +1 since that's what it actually does. Also, as Kai Krakow points out, it's probably not SDL's place to fix broken hardware. I'll add that, if SDL does fix broken hardware, it should probably actually know that it's broken rather than be merely guessing that it is.
So, to the extent that SDL is able to do stuff like this, perhaps it's something better left for the user to configure in some kind of config file.
pj5085
It occurred to me that my simple patch that comments out a few lines of code does not correctly remove the dead zone since the calculation presumably assumes the dead zone has been cut out of the range. Then, while looking into how to make it output the correct range of values, I realized SDL wasn't returning the correct range of values to begin with.
This line of code was already present:
printf("Values = { %d, %d, %d, %d, %d }\n", absinfo.value, absinfo.minimum, absinfo.maximum, absinfo.fuzz, absinfo.flat);
For my joystick this yeilds:
Values = { 0, -127, 127, 0, 15 }
Then this code calculates the coefficients:
In SDL1:
joystick->hwdata->abs_correct[i].coef[0] = (absinfo.maximum + absinfo.minimum) / 2 - absinfo.flat;
joystick->hwdata->abs_correct[i].coef[1] = (absinfo.maximum + absinfo.minimum) / 2 + absinfo.flat;
t = ((absinfo.maximum - absinfo.minimum) / 2 - 2 * absinfo.flat);
if ( t != 0 ) {
joystick->hwdata->abs_correct[i].coef[2] = (1 << 29) / t;
} else {
joystick->hwdata->abs_correct[i].coef[2] = 0;
}
In SDL2:
joystick->hwdata->abs_correct[i].coef[0] = (absinfo.maximum + absinfo.minimum) - 2 * absinfo.flat;
joystick->hwdata->abs_correct[i].coef[1] = (absinfo.maximum + absinfo.minimum) + 2 * absinfo.flat;
t = ((absinfo.maximum - absinfo.minimum) - 4 * absinfo.flat);
if (t != 0) {
joystick->hwdata->abs_correct[i].coef[2] = (1 << 28) / t;
} else {
joystick->hwdata->abs_correct[i].coef[2] = 0;
}
Neither calculates the correct coefficients for the code in the AxisCorrect function.
In SDL1:
if ( value > correct->coef[0] ) {
if ( value < correct->coef[1] ) {
return 0;
}
value -= correct->coef[1];
} else {
value -= correct->coef[0];
}
value *= correct->coef[2];
value >>= 14;
In SDL2:
value *= 2;
if (value > correct->coef[0]) {
if (value < correct->coef[1]) {
return 0;
}
value -= correct->coef[1];
} else {
value -= correct->coef[0];
}
In SDL1, the calculated coefficients are coef[0]=15, coef[1]=-15 and coef[2]=5534751. So with a full-scale input of 127, it calculates an output value of 37835, which is considerably out of range.
In SDL2, the calculated coefficients are coef[0]=30, coef[1]=-30, and coef[2]=1383687. So with a full-scale input of 127, it calculates the same output value of 37835.
I tested it with the 3 joysticks I have, and it produces out-of-range values for all of them.
Anyway, since dead zones are garbage, I just deleted all of that junk and wrote some code that takes the absinfo.minimum and absinfo.maximum values and uses them to scale the axis range to -32767 through +32767.
I also made it detect when a range doesn't have an integer center point, e.g. the center of -128 to + 127 is -0.5. In such cases, if either value to the side of the center is provided, it zeros it, but it otherwise doesn't implement any kind of dead zone. This seemed important with my gamepad which provides only the values of 0, 127, and 255, since without this hack it would never be centered.
Also, the previous minimum output value was -32768, but as that creates an output range that has no true center, I changed the minimum value to -32767.
I tested it with the 3 joystick devices I have and it seems to create correct values for all of them.
Added a hint to control whether a separate thread should be used for joystick events.
This is off by default because dispatching messages in other threads appears to cause problems on some versions of Windows.
Simon McVittie
When watching for hotplug events we can poll the inotify fd, but we
still need to scan /dev/input once per process, otherwise we'll fail
to detect devices that were already connected.
Flatpak[1] and pressure-vessel[2] are known to use user namespaces,
therefore udev event notification via netlink won't work reliably.
Both frameworks provide a filesystem API that libraries can use to
detect them. Do that, and automatically fall back from udev-based
device discovery to the inotify-based fallback introduced in Bug #5337.
[1] <https://flatpak.org/>
[2] <https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/master/pressure-vessel>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Alex S
Evdev headers aren't actually included in the base system (well, it has a private copy), they are available through the devel/evdev-proto port instead. We also have devel/libinotify and devel/libudev-devd shims, I didn't verify whether they work with SDL.
Added support for the PS4 controller gyro and accelerometer on iOS and HIDAPI drivers
Also fixed an issue with the accelerometer on iOS having inverted axes
This improves SDL's ability to detect joystick hotplug in a container
environment.
We cannot reliably receive events from udev in a container, because they
are delivered as netlink events, which are authenticated by their uid
being 0. However, in a user namespace created by an unprivileged user
(for example bubblewrap, as used by Flatpak and Steam's
pressure-vessel-wrap), the kernel does not allow us to map uid 0, and
the netlink events appear to be from the kernel's overflowuid (typically
65534/nobody), meaning libudev cannot distinguish between genuine uevents
from udevd and an attack by a malicious local user.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we only checked for at least one button or key and at least
the X and Y absolute axes, but this has both false positives and false
negatives.
Graphics tablets, trackpads and touchscreens all have buttons and
absolute X and Y axes, but we don't want to detect those as joysticks.
On normal Linux systems ordinary users do not have access to these
device nodes, but members of the 'input' group do.
Conversely, some game controllers only have digital buttons and no
analogue axes (the Nintendo Wiimote is an example), and some have axes
and no buttons (steering wheels or flight simulator rudders might not
have buttons).
Use the more elaborate heuristic factored out from SDL's udev code path
to handle these cases.
In an ideal world we could use exactly the same heuristic as udev's
input_id builtin, but that isn't under a suitable license for inclusion
in SDL, so we have to use a parallel implementation of something
vaguely similar.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This works on capability bitfields that can either come from udev or
from ioctls, so it is equally applicable to both udev and non-udev
input device detection.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Device enumeration via libudev can fail in a container for two reasons:
* the netlink protocol between udevd and libudev is considered private,
so there is no API guarantee that the version of libudev in a container
will understand netlink messages from a dissimilar version of udevd
on the host system;
* the netlink protocol between udevd and libudev relies for security on
being able to check the uid of each message, but in a container with
a user namespace where host uid 0 is not mapped, the libudev client
cannot distinguish between messages from host uid 0 and messages from
a different, malicious user on the host
To make this easier to experiment with, always compile the fallback
code path even if libudev is disabled. libudev remains the default if
enabled at compile time, but the fallback code path can be forced.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Jan Bujak
I wrote a new driver for my gamepad on Linux. I'd like SDL to support it out-of-box, as currently it just treats it as a generic joystick instead of a gamepad. From what I can see the only way to do that is to either 1) pick one of the already supported controllers' PID, VID and button layouts and have my driver send that (effectively lying that it's something else), or 2) submit a preconfigured, hardcoded mapping to SDL.
Both of those, in my opinion, are silly when we already have the Linux Gamepad Specification which standarizes this:
https://www.kernel.org/doc/html/v4.15/input/gamepad.html
Unfortunately SDL doesn't make use of it currently. So I've took it upon myself to add it; patch is in the attachments.
Basically what the patch does is that if SDL finds no built-it controller mappings for a given joystick it then asks the joystick backend to autodetect it, and that uses the relevant evdev bits to figure out which button/axis is which. (See the specs for more details.)
With this patch applied my own driver for my controller works out-of-box with SDL with no extra configuration and is correctly recognized as a gamepad; this is also going to be the case for any other driver which follows the Linux Gamepad Specification.
The index and indices were swapped; Which is fine as long as there are
no gaps in the ABS_HAT* event availability but otherwise things do get confused.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()
Sam Lantinga
Andrei Alexeyev
Ryan C. Gordon
Sjoerd Simons
Paul Cercueil
Ludovico de Nittis
Ozkan Sezer
Simon McVittie
Ethan Lee
Kai Krakow
Sjoerd Simons