Fixes #132

Closes #129

Fixes #137

Bump the upper-bound to `<= 0.51` to allow the latest released `0.51`
bindings to be used, which compile fine with the current codebase.

Fixes #111. This mirrors a similar fix in RetroArch
(https://github.com/libretro/RetroArch/pull/12728) for a similar issue
(https://github.com/libretro/RetroArch/issues/10408).

The crux of the problem is that we attempt to scan a node that
represents the battery of the controller, but the scan hangs due to a
firmware issue. As interacting with the battery is not necessary at this
stage, we can resolve the issue by limiting ourselves to the input
subsystem.

To make it easier to identify the gilrs threads in debuggers and profilers.

The `expect` here on thread spawning failure is the same way `thread::spawn` handles it internally.

Resolves: #149

Fixes #151.
Checks for /.flatpak-info like SDL:
https://github.com/libsdl-org/SDL/blob/c6d9fb1ad71462bc844c6ca41e2ac7fe7cec3883/src/joystick/linux/SDL_sysjoystick.c#L910-L924

It seems this crate does not use any of the streaming functionality
provided by `inotify` via `tokio` (a default feature), and should be
disabled to not suddenly include `tokio` in the dependency graph of
users of `gilrs(-core)`.

Fredrik Fornwall authored Nov 30, 2023 and Arvamer committed Nov 30, 2023

Clear the second axis when an axis event causes a second axis to
be within the dead zone threshold.

  warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
  note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
  note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
  note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions

Bump the upper-bound to `<= 0.52` to allow the latest released `0.52`
bindings to be used, which compile fine with the current codebase.

Daniel Pauls authored Mar 14, 2024 and Arvamer committed Mar 14, 2024

Gamepads may send a change on the axis direction (from -1.0 to 1.0 or
vice-versa) without sending an event for the neutral direction (0.0) for
this axis.
We currently don't handle this behavior, which is why there might be 2
opposite D-pad buttons pressed at the same time, because the internal
gamepad state doesn't release a button.

This commit fixes the behavior by releasing the specific buttons when
the direction of the axis changes.

Should at least fix panics in reported in #162 and #164

Dmitry Marakasov authored Jun 11, 2024 and Arvamer committed Jun 15, 2024

Linux implementation won't build on *BSDs due to lack of epoll, so don't try to use it. This change switches to no-op implementation, but at least allows the module and its consumers such as bevy to build on *BSD. This fixes #145.

Fixes #171