I updated .clang-format and ran clang-format 14 over the src and test directories to standardize the code base.
In general I let clang-format have it's way, and added markup to prevent formatting of code that would break or be completely unreadable if formatted.
The script I ran for the src directory is added as build-scripts/clang-format-src.sh
This fixes:
#6592#6593#6594
* Add braces after if conditions
* More add braces after if conditions
* Add braces after while() conditions
* Fix compilation because of macro being modified
* Add braces to for loop
* Add braces after if/goto
* Move comments up
* Remove extra () in the 'return ...;' statements
* More remove extra () in the 'return ...;' statements
* More remove extra () in the 'return ...;' statements after merge
* Fix inconsistent patterns are xxx == NULL vs !xxx
* More "{}" for "if() break;" and "if() continue;"
* More "{}" after if() short statement
* More "{}" after "if () return;" statement
* More fix inconsistent patterns are xxx == NULL vs !xxx
* Revert some modificaion on SDL_RLEaccel.c
* SDL_RLEaccel: no short statement
* Cleanup 'if' where the bracket is in a new line
* Cleanup 'while' where the bracket is in a new line
* Cleanup 'for' where the bracket is in a new line
* Cleanup 'else' where the bracket is in a new line
I ran this script in the include directory:
```sh
sed -i '' -e 's,#include "\(SDL.*\)",#include <SDL3/\1>,' *.h
```
I ran this script in the src directory:
```sh
for i in ../include/SDL3/SDL*.h
do hdr=$(basename $i)
if [ x"$(echo $hdr | egrep 'SDL_main|SDL_name|SDL_test|SDL_syswm|SDL_opengl|SDL_egl|SDL_vulkan')" != x ]; then
find . -type f -exec sed -i '' -e 's,#include "\('$hdr'\)",#include <SDL3/\1>,' {} \;
else
find . -type f -exec sed -i '' -e '/#include "'$hdr'"/d' {} \;
fi
done
```
Fixes https://github.com/libsdl-org/SDL/issues/6575
This works around udev event nodes arriving before hidraw nodes and the controller being opened twice - once using the Linux driver and once by the HIDAPI driver.
This also fixes a kernel panic on Steam Link hardware due to trying to open the hidraw device node too early.
A delay of 10 ms seems to be a good value, tested on Steam Link hardware.
Refactor the previous sandbox check in a standalone function that also
includes Snap support.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
This will make it possible to have mappings for different controllers
that have the same VID/PID. This happens frequently with some generic
controller boards that have been reused in many products.
Fixes https://github.com/libsdl-org/SDL/issues/6004
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.
