feat(CompositeDevice): Add persist option

[blindedone1458]

• Add CompositeDevice config bool option 'persist'
• If persist is true then continue running CompositeDevice when all SourceDevices have been removed
• Update clear_state for Gamepad targets to default all inputs to stop all input from continuing

This improvement is to handle cases where a SourceDevice is disconnected to maintain the existing TargetDevice

[ShadowApex]

Thanks for this change! I think this is a great option to include :)

There are just a few small things in this to address and I think we can include this.

[blindedone1458]

Thanks for the feedback @ShadowApex ! I've made the updates for the hidraw and usb targets, I totally missed that their tracked state was being used in that way. I do agree that applying InputValue::Bool(false) for all capabilities is a bit inelegant, but it has been working as expected in my testing in that it properly re-centers the joysticks and the triggers are back to zero.

[ShadowApex]

Oh, nice! I thought that might cause issues. Let me also do some testing to double check that this will re-center those joysticks. If everything works, we should be able to merge this in. Thanks!

[pastaq]

I have a few questions on usability. It seems this is only implemented as a config option. That makes me think there are a few cases we need to consider. Don't consider any of these blocking necessarily, but I want to discuss and have a plan at a minimum before we merge.

• As of feat(Manager): add gamepad reordering #284, suspend will stop all target devices and they will be restarted in player order on resume. What will happen to a composite device during suspend that has no sources or targets?
• If the expectation is to use this in a config, what is the expectation for the default configs in /usr? What are the consequences of we enabled this by default on the gamepad configs? I.e. if a user is playing a game and their controller dies, so they plug it in or swap it. Both cases will detect as a new device (different bus type at a minimum) and create a second controller. Should we have some logic to try and connect any of the same type to the original device? If it's a different typ e(ds4 to Xbox for example) and the original controller is persistent, the new controller will be player 2 and player 1 will be permanently unable to be used unless some client sends a StopComposteDevice over dbus. Is there a graceful way to handle clearing this if we get a new controller?
• IMO this would be most useful as selectively enableable from client software. I'd like to see a dbus & CLI option to turn it on/off on the composite device
• Doing the above adds another consideration. What happens if a device has this set to on, has no sources, and it is then set to off?

[blindedone1458]

Definitely some more things to think about @pastaq and probably not for me to necessarily answer as a new contributor. It did give me a few more ideas for edge cases to test for though like if you plug in the controller when was connected via wireless, which currently would create a second persistent CompositeDevice though I have a fix in mind for that.
I do think having a CompositeDevice with no sources active shouldn't remain stuck as Player 1 (which with persist: true would be the case as you point out) so I'll look into having the ordering take that into account as well.

[ShadowApex]

Tested and works great! Once the merge conflict has been resolved, we should be able to merge this in!

Thanks!

[github-actions]

🎉 This PR is included in version 0.47.0 🎉

The release is available on:

• v0.47.0
• GitHub release

Your semantic-release bot 📦🚀