feat(Hardware Support): Add AYANEO NEXT 2 device and capability map config

[pastaq]

Original Author: Gregory Moore greg@sysadmin.network
(cherry picked from commit a414f15)

Modifications from original:

• Add dinput mode support
• Add IMU mount matrix
• Use Left/RightStickTouch for LC/RC so events are unique with default profile
• Add Next 2 to autostart rules
  Signed-off-by: Derek J. Clark derekjohn.clark@gmail.com

Replaces #658
Closes #654

[pastaq]

@abdullamu please test this updated PR.

[abdullamu]

@abdullamu please test this updated PR.

AYANEO NEXT 2 testing report – Elite paddles + gyro working, touchpads unresolved, AYANEO mouse/keyboard mode regression

Hi,

I spent several hours testing the new AYANEO NEXT 2 InputPlumber support and wanted to provide the complete results.

Important context: this is my first time doing this kind of work with Linux/InputPlumber. I performed all testing on my physical NEXT 2, but ChatGPT helped me with the commands, YAML configuration and interpretation of the results. So the observations below are real, but some of my technical interpretation may be incorrect.

Device:
AYANEO NEXT 2
DMI product: AB09
Vendor: AYA
OS: Bazzite

1. ORIGINAL BEHAVIOR / IMPORTANT REGRESSION

Before testing the new NEXT 2 InputPlumber build/profile, the handheld's normal AYANEO controller mode had working mouse/keyboard behavior.

For example, in AYANEO mode I could use the controller/stick to control the desktop mouse and use its normal keyboard/mouse functions.

After installing/running the new NEXT 2 InputPlumber build/profile, this AYANEO mouse/keyboard controller mode stopped behaving normally.

The new build essentially broke the normal AYANEO mouse/keyboard mode on my device while InputPlumber was controlling it.

This is separate from the Xbox controller functionality, which continued to work.

After reverting away from the new setup, I was able to get the normal AYANEO mouse/keyboard behavior back.

So I think this is important to investigate as a possible regression.

2. WHAT I SAW WITH THE NEW NEXT 2 IMPLEMENTATION

During testing, Steam appeared to see two controller devices.

One had the normal Xbox controller functionality.

The other exposed the additional/rear-button functionality.

I do not know whether this is intentional.

If this is the intended architecture, please confirm.

For my use case, having the controls split this way is problematic because I want Steam to see the NEXT 2 as one controller and allow the rear buttons to be configured normally.

3. WORKING SINGLE-CONTROLLER CONFIGURATION

With ChatGPT's help, we created a simplified custom composite that combined the inputs and used Xbox Elite as the target.

The relevant profile was:

version: 1
kind: CompositeDevice
name: AYANEO NEXT 2

single_source: false

matches:

• dmi_data:
  product_name: AB09
  sys_vendor: AYA

source_devices:

• group: gamepad
  evdev:
  name: Microsoft X-Box 360 pad
  phys_path: usb-0000:c6:00.0-4/input0
  handler: event*

• group: buttons
  evdev:
  name: AYANEO COMPOSITE DEVICE
  phys_path: usb-0000:c6:00.0-1/input1
  handler: event*

• group: imu
  iio:
  name: bmi323-imu
  mount_matrix:
  x: [0, 1, 0]
  y: [-1, 0, 0]
  z: [0, 0, 1]

options:
auto_manage: true

target_devices:

• xbox-elite

capability_map_id: aya10

This produced ONE AYANEO NEXT 2 composite containing:

/dev/input/event6
/dev/input/event16
/dev/iio:device0

This was the best configuration I obtained.

4. WHAT WORKED

With this configuration I got:

• Normal Xbox controller functionality
• One Xbox Elite virtual controller
• Rear buttons/paddles
• AYANEO special buttons
• Accelerometer
• Gyroscope

Most importantly, Steam could see the rear buttons as part of the Elite controller instead of requiring the rear controls to exist on another controller.

This seems much more useful from the user's perspective.

5. REAR / SPECIAL BUTTONS

From evtest testing I identified:

F16 = code 186
F17 = code 187
F18 = code 188
F19 = code 189
F20 = code 190
F21 = code 191
F22 = code 192
F23 = code 193

For the physical rear controls I previously identified:

LC = F21
RC = F22

The other rear buttons use F17-F20.

There are also AYANEO special/front buttons producing F-key events, including F16/F23 depending on the physical button.

6. GYROSCOPE / ACCELEROMETER

The NEXT 2 IMU on my unit is:

bmi323-imu
/dev/iio:device0

After adding it to the same composite, InputPlumber showed:

event6
event16
iio:device0

Direct testing through InputPlumber confirmed that gyro/accelerometer motion events were working.

I would appreciate confirmation of the correct production NEXT 2 mount matrix. The matrix we used got the IMU working, but I do not want to claim it is the officially correct orientation.

7. MOUSE + KEYBOARD TARGETS

We also tested:

target_devices:

• xbox-elite
• mouse
• keyboard

This worked without destroying the composite.

InputPlumber successfully created:

xbox-elite = Microsoft X-Box One Elite pad
mouse = InputPlumber Mouse
keyboard = InputPlumber Keyboard

However, simply creating these targets did NOT restore the missing physical touchpad functionality.

8. TOUCHPADS – CURRENTLY UNRESOLVED

At the beginning of today's testing, I remember the NEXT 2 controls behaving with:

Right touchpad = mouse
Left touchpad = D-pad

Later during the testing this functionality disappeared, and I could not reproduce it.

The AYANEO composite device currently exposes:

event4 = pointer
event6 = keyboard

USB ID:
1c4f:0002

event4 advertises:

BTN_LEFT
BTN_RIGHT
BTN_MIDDLE
REL_X
REL_Y
REL_WHEEL
REL_WHEEL_HI_RES

However, with InputPlumber stopped, running:

sudo evtest /dev/input/event4

and physically using either touchpad produced no output.

We also tested the AYANEO hidraw interfaces:

hidraw1 = interface 1.0
hidraw3 = interface 1.1
hidraw4 = interface 1.2

I tested them with hexdump while operating the physical touchpads and did not observe touchpad data.

9. IMPORTANT CORRECTION FROM OUR TESTING

At one point we thought REL_WHEEL activity on event4 was coming from one of the touchpads.

That interpretation was WRONG.

I later determined that the activity was generated by the LEFT STICK when the handheld was placed into AYANEO controller/mouse mode.

I am including this correction so nobody investigating this wastes time based on our earlier assumption.

10. ATTEMPT TO ADD event4 TO THE COMPOSITE

We attempted to add the AYANEO pointer interface as another evdev source.

After that change, InputPlumber failed to create the composite and:

inputplumber device 0 info

returned:

Error: "Composite device does not exist with number: 0"

We immediately reverted this change.

Therefore I do not know the correct way to integrate the physical pointer/touchpad functionality.

11. QUESTIONS FOR THE DEVELOPERS

12. Is the current NEXT 2 implementation intentionally supposed to result in the normal controller and additional/rear controls appearing separately to Steam?

13. If yes, what is the reason for this architecture?

14. Would it be preferable to expose the NEXT 2 as ONE Xbox Elite controller, with the four rear controls mapped as Elite paddles?

15. Is aya10 already intended to accomplish this, meaning our original configuration was incorrect?

16. Is breaking/disabling the normal AYANEO mouse/keyboard controller mode expected while the NEXT 2 InputPlumber profile is active, or is this a bug?

17. How are the two physical touchpads actually exposed by the NEXT 2?

18. Is there a hardware/firmware command required to activate or switch the touchpads into the expected mode?

19. Why could the touchpads work earlier and then stop producing input after the controller/InputPlumber configuration changed?

20. What is the correct BMI323 mount matrix for the production NEXT 2?

21. Is there anything from our working single-Elite-controller configuration that would be useful to incorporate into the official implementation?

22. I CAN HELP TEST

I have the physical AYANEO NEXT 2 available and I am happy to help test this further.

Please give me exact commands and I can provide raw output from:

• evtest
• udevadm
• libinput
• InputPlumber
• journalctl
• hidraw
• IIO/gyro
• Steam controller detection

I can also test modified YAML files or development builds.

Because I am new to Linux development, exact commands/instructions would be helpful and will reduce the chance of me testing the wrong thing.

The main useful result from today's testing is that we DID manage to combine:

normal controller + rear buttons + special buttons + BMI323 gyro

into ONE Xbox Elite composite controller, and that configuration worked.

The two remaining issues are:

1. Touchpad support.
2. The new NEXT 2 build/profile interfering with the normal AYANEO mouse/keyboard controller mode.

I hope this testing helps. Please let me know what you want me to test next.

[pastaq]

@abdullamu thank you for sticking with this. That is a lot of info, I'll try and cover it all.

• No, it should not make multiple composite devices. This probably means my config has a device marked unique or max sources are hit. I'll need LOG_LEVEL=debug inputplumber logs to determine which, along with inputplumber device X info for each composite device.
• I suspect the touchpads are only active in either the xinput or dinput mode. try toggling with lc+rc to see if there is a difference.
• It will help to identify which event device has keyboard/mouse events so we can try to avoid grabbing it, unless its the same one as the one that produces paddles and face buttons which will complicate things.
• It was unclear, but are you saying the button map is wrong? If so, what is wrong?

To ensure we cover all bases, please provide the following (This is highly specific, please follow directions precisely):
First, mask inputplumber with sudo systemctl mask inputplumber && sudo systemctl stop inputplumber to prevent it form auto starting in systemd.

Then provide the following for ALL modes using the config from this PR by swapping with LC + RC BEFORE starting InputPlumber
cat /proc/bus/input/devices > devices_MODE.txt (swpt MODE for xinput/dinput)
sudo libinput debug-events | sudo tee debug_events_MODE.txt
for each device that produces events from the gamepad or touchpad, a copy of evtest results

Then run inputplumber manually with debug logging: sudo LOG_LEVEL=debug inputplumber 2>&1 | tee inputplumber.log and upload inputplumber.txt after all the remaining testing is done:
inputplumber devices list > devices_list.txt
inputplumber device X info > device_X_info.txt (swap X for each composite device index)
a list of events that don't work with inputplumber device X test (q button will quit)

After all testing is done, sudo systemctl unmask inputplumber to re-enable systemd autostart
Thanks