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

[pastaq]

Original Author: Gregory Moore [email protected]
(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 [email protected]

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

[abdullamu]

next2-inputplumber-diagnostics.zip
Hi @pastaq,

I completed the testing you requested using the config from the PR. I’ve attached next2-inputplumber-diagnostics.zip containing all the raw captures, evtest results, composite-device info, and the full debug log.

MAIN FINDINGS

1. TWO COMPOSITE DEVICES ARE CREATED

inputplumber devices list reports:

• Composite 0 — AYANEO NEXT 2
• Composite 1 — AYANEO NEXT 2

With the PR config in DInput mode:

• Composite 0 sources: /dev/input/event4
• Composite 1 sources: /dev/input/event6 + /dev/iio:device0

The actual physical DInput gamepad is not included in either composite.

2. XINPUT VS DINPUT

The same physical controller path changes identity when switching modes with LC+RC:

XInput:

• Name: Microsoft X-Box 360 pad
• VID:PID: 045e:028e

DInput:

• Name: AYANEO Controller
• VID:PID: 4001:0428

Physical path in both modes:
usb-0000:c6:00.0-4/input0

I noticed the PR config's DInput entry still matches:

name: Microsoft X-Box 360 pad

with:

capability_map_id: dinput_generic

However, on my NEXT 2 the physical controller is actually named AYANEO Controller in DInput mode.

This seems particularly relevant because the physical DInput gamepad (event15 during these tests) did not end up in either composite.

3. inputplumber device X test

Composite 0:

• Nothing worked.

Composite 1:

• Gyro works.
• Buttons represented as keyboard keys work.
• Normal gamepad controls do NOT work.
• Touchpads do NOT work.

This corresponds with Composite 0 containing only event4 and Composite 1 containing event6 + IMU, while the actual gamepad event15 is missing.

4. RAW DINPUT BEHAVIOR

In DInput mode:

• event4 = AYANEO COMPOSITE DEVICE
  Pointer interface: REL_X/Y, wheel, mouse buttons.

• event6 = AYANEO COMPOSITE DEVICE
  Keyboard/special-button interface.

• event15 = AYANEO Controller
  Physical gamepad.

The mouse events seen on event4 appear to be generated by the controller's desktop/mouse mode (for example stick movement), rather than identifiable touchpad events.

5. RAW XINPUT BEHAVIOR

In XInput mode:

• event15 = physical Microsoft X-Box 360 pad.
• Normal sticks, triggers, D-pad and gamepad buttons work in evtest.
• event4 advertises pointer capabilities, but touchpad-only testing generated no events.
• event6 continues to generate the special keyboard/button events.

6. TOUCHPADS

I could not identify reliable touchpad events in either XInput or DInput mode.

In XInput mode I occasionally observed tiny ABS_RZ 0→1→0 pulses while testing the right touchpad, but similar pulses can occur without a clear corresponding touch. Therefore I cannot confirm that these originate from the touchpad.

libinput debug-events also did not reveal identifiable touchpad activity in XInput mode.

7. BUTTON MAP

I don't currently think the button map itself is the main problem.

Raw testing showed:

• LC = KEY_F21
• RC = KEY_F22
• Other special/rear buttons generate their F-key events.

With my previously working aya10 + Xbox Elite setup, the rear buttons worked correctly.

The main problem with the PR configuration therefore appears to be device/source grouping and the duplicate composites rather than an obviously incorrect button map.

8. ADDITIONAL OBSERVATION

While testing the new PR/InputPlumber setup, the normal AYANEO desktop mouse/keyboard controller behavior stopped working as it normally does outside this setup.

The attached ZIP contains 15 files, including:

• XInput and DInput /proc/bus/input/devices captures
• libinput debug logs
• evtest captures
• devices_list.txt
• device_0_info.txt
• device_1_info.txt
• full LOG_LEVEL=debug InputPlumber log

Let me know what you want me to test next and I’ll follow the steps exactly.

[pastaq]

Let me know what you want me to test next and I’ll follow the steps exactly.

This file does not contain the devices list when in dinput mode. It also only has one device X info set from one of the modes and it is unlabeled.

Please stop using your AI and do this yourself manually or we will be here forever. It is very exhausting talking to LLM output. If I don't have a complete picture of the entire devices state at the time of the test I'm not going to be able to identify everything fully and fix the config.

I need to know:

• Which devices are triggering the duplication (this is the inputplumber device 0 |1 info we've been doing and it tells me where two devices are matching to generate a second controller.
• The physical device each of those enumerated as this run because they change over time (event4 might be a keyboard on one boot or a touchscreen on another). This is what /cat /proc/bus/input/devices is for.
• I need this for, XInput, Dinput, mouse mode from xinput, mouse mode from dinput.
• I need to know what event devices in mouse mode produce events to I can verify they aren't grabbed by the config so mouse mode continues to work.

[abdullamu]

i contacted you on Discord, i think it will be easier to communicate there.