If one remaps the Mavlink profile in Cockpit, the changes are not retained in QGC

[rafaellehmkuhl]

This happens because we change the buttons mapping in the Cockpit side, not in the Ardupilot side.

The solution is the same proposed for #263.

[ES-Alexander]

@rafaellehmkuhl I don't think there's anything we can reasonably do about this.

While it's important for Cockpit to be able to set a new button function in an ArduPilot firmware, how those functions correspond to buttons is up to the control station software. Cockpit is fundamentally less restricted than QGC in terms of joystick button options, and if we try to consistently change ArduPilot's button function parameters whenever we re-map Cockpit's joystick buttons then it loses the possibility of using only a single MANUAL_CONTROL button index for multiple physical buttons that correspond to the same function, and also could be un-reconcilable if there are multiple joysticks connected that don't have identical orderings and button setups.

What makes the most sense (to me) would be Cockpit treating the ArduPilot BTNn_FUNCTION parameters as an array of values, and if a button is assigned to an ardupilot function that is not already in the array then it needs to reassign an available slot in the array, or fail/reject the button assignment if all slots are already (uniquely) full and mapped to buttons on currently connected joysticks. If a joystick profile is selected that uses ArduPilot button functions that are not currently assigned in the parameters then it can show a warning/error and allow re-assigning the parameters as necessary (if it's possible to do so).

[rafaellehmkuhl]

We now support mapping any vehicle function as of #452.

As explained by @ES-Alexander it's an opinated matter, and we ended up implementing so that buttons already mapped inside the function are not remapped in Cockpit, and only unmpapped functions in the vehicle are being remapped in the vehicle itself (parameter being changed).

With that, we are able to support more than 16 buttons and also to support other protocols, including Cockpit Actions.

To finalize that, I've also talked to @Williangalvani, and we decided to slowly move from the BTNn_FUNCTION parameters to regular MAVLink messages, so that this will no longer be an issue.