JoystickSDL: Show non-gamepad axes and only show gamepad axes if they are valid

[gillamkid]

Issue

Currently QGC assumes numGapepadAxes == numJoystickAxes, which cannot be assumed. numGamepadAxes can be less than, equal to, or greater than numJoystickAxes.

QGC is also assuming a joystickAxisId represents the same axis as a gamepadAxisId. This cannot be assumed

ex. A gamepad may map buttons to a gamepad axes, so even if numJoystickAxes == 0 there may still be a gamepad axis

ex. With the SDL gamepad interface, a controller can only have 2 joysticks. Some devices that support the SDL gamepad interface have more than 2 joysticks (ex. UXV SRoC or Steam Controller). The SDL joystick interface supports more than 2 joysticks. A joystick axis may not map to be a gamepad axis.

Before

After

Steps to Reproduce

1. open QGC
2. connect to a vehicle
3. connect a controller which supports the SDL gamepad interface but has more than 2 joysticks (ex. Steam Controller or this Linux virtual UXV SRoC )
4. Go to menu -> vehicle configuration -> Joystick -> configuration
5. If using QGC Daily, there will be a joystick on the controller which will not be mapped to an axis in the configurator (moving the joystick has no affect on any of the axis output displays). With the change made in this PR, all joysticks should have a visible affect on an axis in the joystick configuration page.

Comments

Most controllers do not have the issues fixed with this PR because they are true gamepads and don't have any axes not mapped/represented in the SDL gamepad interface. I tested with a couple popular controllers (x-box 360 controller and a 8bitDo Ultimate C bluetooth controller) and they had no hidden axes. The QGC joystick configuration page for these controllers will have no visible difference before and after this PR

Build Environment

I did the development/testing for this PR on Ubuntu 24.04

[HTRamsey]

I will test this on my sroc within a few days

[Copilot]

Pull Request Overview

This PR fixes issues with joystick axis mapping in QGC by properly handling the distinction between SDL gamepad axes and SDL joystick axes. Previously, QGC incorrectly assumed that the number of gamepad axes equals joystick axes and that axis IDs represent the same axes across both interfaces.

• Separates gamepad axes from non-gamepad axes to handle controllers with more joystick axes than supported gamepad axes
• Updates the constructor to accept separate lists for gamepad and non-gamepad axes instead of a single axis count
• Modifies axis reading logic to properly map between gamepad and joystick interfaces

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
src/Joystick/JoystickSDL.h	Updates constructor signature and adds member variables to track gamepad vs non-gamepad axes separately
src/Joystick/JoystickSDL.cc	Implements logic to discover and categorize axes, updates constructor, and modifies axis reading to handle both interface types

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[gillamkid]

I will test this on my sroc within a few days

Great! I have not yet tested with a physical SRoC

Note: If the device you are running uses Android, this PR will not affect it. This PR touches the JoystickSDL class, which uses the SDL3 library, where on Android QGC uses JoystickAndroid, which does not use the SDL3 library for getting joystick inputs

The 2 different libraries have quite different behavior. For example, if I connect a Google Stadia Controller or a 8BitDo Ultimate 2 wireless controller to QGC on Android, it recognizes the D-pad as 2 axes, while if I connect those same controllers to Linux, the D-pad is not recognized as additional axes. Even with this PR the D-pad is still not recognized as additional axes on Linux

My specific motivation for this PR was this: Our company's target QGC platform is an SRoC running Android. On android with the SRoC, there are enough axes for all the controls we want (because QGC considers the SRoC's D-pad as 2 axes and counts the SRoC's trigger levers as axes... I think). I don't have a physical SRoC, but still develop our company's QGC fork using a Linux machine and simulation. I wanted a controller on Linux that will better mimic SRoC behavior on Android