Repository navigation
Change target device for Qualcomm based devices #695
Description
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.yaml50-ayn_odin2.yaml50-ayn_odin3.yaml50-ayn_thor.yaml50-retroid_pocket5.yaml50-retroid_pocket6.yaml50-retroid_pocket_flip2.yaml50-retroid_pocket_mini.yaml50-retroid_pocket_nova.yaml50-konkr_pocket_fit.yaml50-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-steamor8bitdo-u2 - change to
unified-gamepad, expect distributions to override it when it makes sense
Reacted by Radical and Victoria Brekenfeld
Activity
Drakulix commentedon Sep 7, 2026
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 commentedon Sep 7, 2026
@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:
The Elite limitation is documented in [PR #670](#670): the vendor Android configuration exposes mapping values
0–24for LC1/RC1, but these only duplicate existing controller functions, such as A/B, rather than reporting independent paddles. I also tested values25and26. 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 commentedon Sep 7, 2026
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.
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:
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:
Until that requirement is met this isn't something I'm going to consider.