Change target device for Qualcomm based devices

[jenneron]

Some (all?) of these devices have gyroscope supported by libssc which is worked on at #590, however these devices currently use xbox-elite target which doesn't support gyroscope

• 50-ayaneo_pocket_s2.yaml
• 50-ayn_odin2.yaml
• 50-ayn_odin3.yaml
• 50-ayn_thor.yaml
• 50-retroid_pocket5.yaml
• 50-retroid_pocket6.yaml
• 50-retroid_pocket_flip2.yaml
• 50-retroid_pocket_mini.yaml
• 50-retroid_pocket_nova.yaml
• 50-konkr_pocket_fit.yaml
• 50-konkr_pocket_fit_elite.yaml

We need to check what devices have gyroscope and decide whether we want to change the target.

We could either:

• change to a more compatible target, for example hori-steam or 8bitdo-u2
• change to unified-gamepad, expect distributions to override it when it makes sense

@justradical @mydanyi @Drakulix

[Drakulix]

I assume I was pinged on this because I submitted the ayaneo-pocket-s2 config.

I don't have a particular preference here, in my postmarketos branch this is overridden by steamos-manager anyway to emulate a steam deck. In that mode I have verified #590 working together with linux-msm/hexagonrpc#21 though, so some profile that does expose the gyroscope by default would definitely make sense for the pocket s2 (so that it works out-of-the-box when all of this is finally upstream).

[mydanyi]

@jenneron Thanks for pinging me. I'm happy to help with hardware testing and feedback for both KONKR devices.

The current status on my side is:

• KONKR Pocket FIT (SM8650): The controller issues are largely resolved. Standard controls, LC/RC, LC1/RC1, and rumble have all been verified on the physical device. However, gyroscope input is still not working in my setup.
• KONKR Pocket FIT Elite (SM8750): Standard controls, LC/RC, and rumble have been verified, but independent LC1/RC1 support remains blocked by the underlying MCU firmware/protocol output limitation. Gyroscope input is also still not working in my setup.

The Elite limitation is documented in [PR #670](#670): the vendor Android configuration exposes mapping values 0–24 for LC1/RC1, but these only duplicate existing controller functions, such as A/B, rather than reporting independent paddles. I also tested values 25 and 26. The MCU accepted and read back both values, but pressing LC1/RC1 produced no evdev events and no corresponding SPI state changes across 5,306 high-rate samples. Independent support therefore still requires firmware/protocol output that Linux can observe.

I'm happy to test a new target that exposes gyroscope input, and I don't have a firm preference between the proposed targets yet. My concern is making sure that switching targets preserves the controls, paddles, and rumble that already work. The Elite's LC1/RC1 limitation is a separate source-side issue; changing the target alone cannot provide the missing input events.

If you have a recommended test branch, dependency versions, and configuration, please let me know. I can help validate them on both devices and report results for gyroscope input and the existing controller functionality.

[pastaq]

The default target is set to provide the most supported feature set while maintaining accurate button glyphs in games and UI's. We do the same for all x86 hardware that also supports an IMU. It is not able to be set to a universally valid input device because that doesn't exist.

• Xbox devices lack gyro but have the correct glyphs.
• PS devices supports all input, but doesn't have the correct glyphs.
• Steam Horipad supports all input and has the correct glyphs, but doesn't support rumble output.
• Deck and Deck-uhid supports all input and has the correct glyphs, but has limited support outside steam input.
• 8BitDo Ultiamte 2 supports all input and has the correct glyphs, but has limited support outside steam input.

Given the available options, the most intuitive default target for most users is the xbox-elite or xbox-series, depending on if back paddles are supported. It is much worse for the majority of users to have buttons that don't match than missing gyro. We will get a lot more complaints if we do the opposite. Advanced users and distros can make their own config to set their preferred targets in /etc/inputplumber/devices.d if they want to override the defaults.

Additionally, there are multiple 3rd party tools that can allow users to set the target device on the fly:

• DeckyPlumber is a decky loader plugin for the Steam UI.
• OpenGamepadUI has an advanced UI for configuring target devices and input profiles.
• There are various GUI tools for the desktop that have been created as well.

I currently don't have any plans to re-litigate the default target device for any existing config. The only exception I would make would be if both of these were true:

• We add a Nintendo Switch Pro controller target device
• The CompositeDevice in question uses the Nintendo layout

Until that requirement is met this isn't something I'm going to consider.