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

[EightQuarterBit]

This PR implements support for the AYANEO NEXT 2, according to the issue opened here. After looking through the repo it seemed simple enough to implement myself, though I did hand off the legwork of writing the YAML files to Claude Sonnet 5, as well as having it verify I wasn't missing a file that needed to be modified.

The exact prompt I gave to Claude was:

If I wanted to add support for my AYANEO NEXT 2 according to this issue: #654 what modifications would I need to perform to the files in the repo?

That spat out the device and capability map, mostly cribbed from existing Ayaneo config. I went back and forth with Claude to see if there were better options than an Xbox Elite controller for this device, and to check up on LC/RC button functions, but in the end the only change I made to the generated config was renaming the "Ayaneo Button" from "Logo". I named it "Logo" in the issue, but it's labeled "Ayaneo Button" in existing capability maps, so that seemed like the better convention.

Tested on Bazzite Deck 44 by installing to /etc/inputplumber/devices.d/ and /etc/inputplumber/capability_maps.d/. After restarting InputPlumber, the built-in controller appeared as an Xbox Elite controller as expected. Back buttons were visible and successfully mapped/tested in Steam. The "Ayaneo Button" also correctly summons Quick Access. "T" button is mapped to QuickAccess2, which seems to take a screenshot in-game at the moment.

A second, "ghost" Xbox Elite 2 controller also appeared on the system, though I've read reports of other users encountering the same behavior, so I'm assuming that's not a misconfiguration with these files. Claude seems to think it's InputPlumber generating a child Xbox Elite controller from my remapped physical controller. Surfacing it just in case that's not expected.

The "=" button was left emitting its default key combo since there didn't seem to be a better unopinionated option.

The LC and RC buttons, of course, weren't visible in Steam for mapping, since they aren't present on an Xbox Elite controller.

I haven't yet found a completely satisfactory way to test the gyro/accelerometer orientation, since that's not implemented on the Xbox Elite controller. There's no kernel-level mount matrix for this under /sys/bus/iio/devices/iio:device0/in_mount_matrix, but watching the raw accelerometer output with watch -n 0.2 'for f in /sys/bus/iio/devices/iio:device0/in_accel_x_raw; do echo "$f: $(cat $f)"; done' (repeat for Y and Z) it seemed to generate sensible values.

Likewise I could not test setting the controller LED rings via InputPlumber in any way I or Claude could determine.

Happy to test further on either of those features if a more thorough test regimen can be recommended.

[abdullamu]

I also own an AYANEO NEXT 2 (sys_vendor: AYA, product_name: AB09) and have been testing it on Bazzite.

Before finding this PR, I managed to get InputPlumber working using a local profile based on the existing AYANEO profiles. I can confirm the following special-button events on my unit:

LC → KEY_F21
RC → KEY_F22
AYANEO button → KEY_F23
Another special button → KEY_F16

The special-button events are coming from the AYANEO COMPOSITE DEVICE interface at usb-0000:c6:00.0-1/input1 on my unit.

Using the aya8 capability map and mapping F23 to QuickAccess successfully makes the AYANEO button open Steam's Quick Access Menu.

I also initially encountered duplicate composite devices when matching both AYANEO COMPOSITE DEVICE interfaces. Restricting the profile to the input1 interface resulted in a single working composite device.

I’m happy to test this PR or provide any additional evtest, udevadm, DMI, InputPlumber logs, or hardware information from a second physical NEXT 2 if that would be useful.

I’m also seeing some unrelated Bazzite/Linux platform issues such as unreliable battery percentage and incomplete temperature/power telemetry, but I assume those are outside InputPlumber’s scope.

[pastaq]

Interesting device. I have some questions.

Can you label each button on this picture:

Also, what types of events do the touchpads produce in evtest? Do they have a physical click? It would be cool to get those working like a steam deck. Hopefully they are ABS and not REL events.

[pastaq]

Looked at your Issue to get the answer to my previous questions. Just a couple of nits to button this up for now.

I'd like to try and get the touchpads to act as steam deck touchpads as well, but that will require a driver and only works if the events are ABS_X/Y

[pastaq]

For this device, since it has enough buttons for left/right paddle 1&2 and QuickAccess2, these mappings will get swallowed. It would be more useful to map LC and RC to Left/RightStickTouch. The default profile will make these onto Left/RightPaddle buttons

[pastaq]

Does this device need an IMU matrix for the axes to be properly mapped?

[abdullamu]

I did some additional testing on a physical AYANEO NEXT 2 to help with the open questions.

IMU / mount matrix

The IMU is detected as:

bmi323-imu

There is no generic in_mount_matrix, but Linux exposes separate mount matrices:

/sys/bus/iio/devices/iio:device0/in_accel_mount_matrix

/sys/bus/iio/devices/iio:device0/in_anglvel_mount_matrix

Both return:

1, 0, 0;
0, 1, 0;
0, 0, -1

I also tested the raw accelerometer values in known physical orientations.

Flat, screen facing up:

X: -53
Y: 54
Z: 4026

Vertical, top edge facing up:

X: -28
Y: -4041
Z: 411

Vertical, right edge facing up:

X: -4152
Y: 46
Z: 15

So the kernel is already exposing a Z-axis inversion mount matrix for both the accelerometer and gyroscope.

If additional orientation testing is needed to determine whether InputPlumber should define its own matrix, I can test it.

Controller modes

I also confirmed that pressing LC + RC can cause the physical controller to re-enumerate between:

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

and:

AYANEO Controller
VID: 4001
PID: 0428

The /dev/input/event* number can remain the same even though the device identity and capabilities change.

There also appears to be another firmware/controller sub-mode accessible through LC + RC, but I haven't found a reproducible difference in its exposed evdev capabilities yet, so I don't want to make assumptions about what it does.

Touchpads

I'm still investigating these.

So far I have not found reproducible ABS_X/ABS_Y or REL_X/REL_Y events corresponding to touchpad movement through the normal controller evdev interface.

In Xbox mode I observed repeated:

ABS_RZ 1
ABS_RZ 0

However, these events also occur while the NEXT 2 is completely untouched, so I don't think they can safely be identified as touchpad events.

The AYANEO composite device exposes three HID interfaces:

/dev/hidraw1 -> interface 00
/dev/hidraw3 -> interface 01
/dev/hidraw4 -> interface 02

They identify as:

VID: 1c4f
PID: 0002
AYANEO COMPOSITE DEVICE

I tested the touchpads directly against these raw HID interfaces.

Left touchpad: no obvious output or changing raw HID data was produced during movement or pressing.

Right touchpad: also produced no obvious output or changing raw HID data during movement or pressing.

So at least with the current firmware/controller modes and the interfaces I have tested, neither touchpad appears to expose obvious usable ABS, REL, or raw HID movement data.

I will continue testing if there is a preferred method for capturing the touchpads, but I don't want to claim a mapping until the behavior is reproducible.

LC / RC mapping

I also saw the suggestion to map LC/RC to LeftStickTouch / RightStickTouch instead of LeftTop / RightTop.

I can test the updated mapping on the physical NEXT 2 once that change is available.

[Valkirie]

Which of those controller modes produces the expect key chords (F16...F23) ?

[abdullamu]

I tested this directly on the physical NEXT 2.

The expected F16–F23 inputs are produced in all controller modes. They come from the separate AYANEO COMPOSITE DEVICE, so switching the main gamepad between AYANEO Controller and Microsoft X-Box 360 pad does not stop these events.

Confirmed mappings on my unit:

F16 = left-side front special button (left side of steamkey/xboxkey)

F17 = rear left lower button
F18 = rear right lower button
F19 = rear left upper button
F20 = rear right upper button

F21 = LC
F22 = RC
F23 = AYANEO button

I also confirmed two other front buttons:

• Right-side Show Desktop button (right side of ayaneo key) = Left Meta + D (Win + D)
• Left-side Steam button opens Steam, but it does not appear on the same evtest interface I was monitoring, so I have not identified its exact event/chord yet.

So for your question specifically: F16 through F23 continue to work in every controller mode I tested.

[pastaq]

Thanks for the feedback. The LC/RC mode switch is annoying, pretty terrible design decision there.

When in AYANEO mode, does the controller evdev appear to use xinput or dinput mapping? I suspect dinput as many android controllers use that and it's possible this is an MCU they carried over from their ARM line. If you're unsure, post the full results of evtest on that device without pressing any buttons or joysticks so I can review what events are enabled.

For the touchpads, we should not assume it's part of the AYANEO composite controller at all. I expect there will be two similarly named hidraw and evdev interfaces. If they work at all in Linux they will be detectable by one or both methods.

You might be able to identify the event devices using sudo libinput debug-events, which will monitor all evdevs for input that libinput recognizes. From there we can figure out the hidraw by VID:PID.

It would also be very helpful to get a copy of cat /proc/bus/input/devices so I can manually inspect for the devices we're looking for.

As for validating the x/y/z orientation, I haven't memorized which is which, so a physical test would be most useful for validation. The most straightforward would be to leverage the deck target's deck PID and test it in the steam controller calibration menu. To do that you will need to change this line of the source code:

InputPlumber/src/input/target/steam_deck.rs

Line 66 in 23f84b7

product_id: ProductId::Generic,

To product_id: ProductId::SteamDeck,
Then recompile, reinstall the new binary, and run inputplumber device 0 targets set deck

If that's too big a challenge then I'll validate on a device I've already confirmed accurate against your results.

[abdullamu]

Additional testing based on your suggestions:

AYANEO controller mode

I switched the physical controller specifically into AYANEO mode, stopped InputPlumber, and captured the full evtest capabilities.

The device enumerates as:

AYANEO Controller
VID: 4001
PID: 0428

Its capabilities are:

EV_KEY:
BTN_SOUTH
BTN_EAST
BTN_C
BTN_NORTH
BTN_WEST
BTN_Z
BTN_TL
BTN_TR
BTN_TL2
BTN_TR2
BTN_SELECT
BTN_START
BTN_MODE
BTN_THUMBL
BTN_THUMBR

EV_ABS:
ABS_X      -32768..32767
ABS_Y      -32768..32767
ABS_Z      -32768..32767
ABS_RZ     -32768..32767
ABS_GAS    0..255
ABS_BRAKE  0..255
ABS_HAT0X  -1..1
ABS_HAT0Y  -1..1

So this appears to be the DInput/generic HID-style mapping you suspected rather than the Xbox/XInput mapping.

Touchpads / libinput

I also ran:

sudo libinput debug-events

The only AYANEO pointer device detected by libinput is:

event4  AYANEO COMPOSITE DEVICE  cap:p

/proc/bus/input/devices identifies it as:

Bus=0003 Vendor=1c4f Product=0002
Name="AYANEO COMPOSITE DEVICE"
Phys=usb-0000:c6:00.0-1/input0
Handlers=mouse0 event4
EV=17
REL=903

There is also the separate keyboard interface ( i have physical keybored attached) :

Bus=0003 Vendor=1c4f Product=0002
Name="AYANEO COMPOSITE DEVICE"
Phys=usb-0000:c6:00.0-1/input1
Handlers=sysrq kbd event5

And separately the native gamepad:

Bus=0003 Vendor=4001 Product=0428
Name="AYANEO Controller"
Handlers=event16 js0

I tested both physical touchpads while running libinput debug-events:

• left touchpad movement: no event
• left touchpad physical click: no event
• right touchpad movement: no event
• right touchpad physical click: no event

I then directly monitored the AYANEO relative mouse interface:

sudo evtest /dev/input/event4

and repeated movement + physical click on both touchpads. Again, neither touchpad produced any events.

So although Linux exposes an AYANEO REL mouse interface, the physical touchpads do not appear to be generating events through it in the tested state.

I also don't see a separate AYANEO ABS_X/Y touchpad evdev device in /proc/bus/input/devices.

Earlier I also checked the AYANEO hidraw interfaces and did not find obvious changing reports from either touchpad.

If there is another lower-level method you would like me to use to determine whether the touchpad hardware is exposed at all, I'm happy to test it.

IMU

For IMU orientation, I would prefer not to recompile InputPlumber on this device.

I have already provided the kernel mount matrices and physical orientation measurements from the NEXT 2. If you can validate those against a known-good device, that would be preferable.

I'm happy to perform any additional tests that can be done on the existing installation without recompiling InputPlumber.

[pastaq]

Please provide a full list of ALL input devices from cat /proc/bus/input/devices and a list of ALL hidraw devices detected by sudo hid-recorder

[abdullamu]

I already captured the full /proc/bus/input/devices output. Here is the complete input-device set from that capture (InputPlumber was stopped and the controller was in AYANEO mode):

Lid Switch
Bus: 0019
Vendor: 0000
Product: 0005
Handler: event0

Power Button
Bus: 0019
Vendor: 0000
Product: 0001
Handler: event1

AT Translated Set 2 keyboard
Bus: 0011
Vendor: 0001
Product: 0001
Handler: event2

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS
VID: 0b05
PID: 1aae
event3

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS Consumer Control
VID: 0b05
PID: 1aae
event6

Video Bus
event7

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS System Control
VID: 0b05
PID: 1aae
event8

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS
VID: 0b05
PID: 1aae
event9

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS Mouse
VID: 0b05
PID: 1aae
mouse1 / event10

ASUSTeK ROG STRIX SCOPE II 96 WIRELESS
VID: 0b05
PID: 1aae
event11

GXTP6972:00 27C6:0139
Bus: I2C
VID: 27c6
PID: 0139
mouse2 / event12

GXTP6972:00 27C6:0139 Stylus
Bus: I2C
VID: 27c6
PID: 0139
mouse3 / event13

GXTP6972:00 27C6:0139 UNKNOWN
Bus: I2C
VID: 27c6
PID: 0139
event14

PC Speaker
event15

HD-Audio Generic HDMI/DP,pcm=3
event17

HD-Audio Generic HDMI/DP,pcm=7
event18

HD-Audio Generic HDMI/DP,pcm=8
event19

HD-Audio Generic HDMI/DP,pcm=9
event20

HD-Audio Generic Mic
event21

HD-Audio Generic Headphone
event22

steamos-manager
Bus: 0006
VID: 28de
PID: 0000
event26

AYANEO COMPOSITE DEVICE
Bus: USB
VID: 1c4f
PID: 0002
Phys: usb-0000:c6:00.0-1/input0
Handler: mouse0 / event4
EV=17
REL=903

AYANEO COMPOSITE DEVICE
Bus: USB
VID: 1c4f
PID: 0002
Phys: usb-0000:c6:00.0-1/input1
Handler: keyboard / event5
EV=100013

AYANEO Controller
Bus: USB
VID: 4001
PID: 0428
Phys: usb-0000:c6:00.0-4/input0
Handler: event16 / js0
EV=1b
ABS=30627

Microsoft X-Box 360 pad 0
Bus: virtual
VID: 28de
PID: 11ff
Handler: event23 / js1

The AYANEO Controller changes identity depending on firmware mode. In Xbox mode I have also captured the physical controller as:

Microsoft X-Box 360 pad
Bus: USB
VID: 045e
PID: 028e
Phys: usb-0000:c6:00.0-4/input0

For hidraw, I previously enumerated all /dev/hidraw* devices using udevadm. The AYANEO composite device appeared on:

/dev/hidraw1
AYANEO COMPOSITE DEVICE
VID: 1c4f
PID: 0002

/dev/hidraw3
AYANEO COMPOSITE DEVICE
VID: 1c4f
PID: 0002

/dev/hidraw4
AYANEO COMPOSITE DEVICE
VID: 1c4f
PID: 0002

The other hidraw devices in that capture belonged primarily to my external ASUS ROG STRIX SCOPE II 96 WIRELESS keyboard (VID 0b05, PID 1aae).

Important: that hidraw enumeration was done with udevadm, not sudo hid-recorder.

If you specifically need the device list exactly as reported by sudo hid-recorder, I can run that now and send the complete output as well.

[pastaq]

Please just give me the complete logs in the exact format I'm asking for. The back and forth is just wasting both of our time. I'm looking to see if there's something you're missing. Filtering the results based on your assumptions is preventing me from doing that.

[pastaq]

Superseded by #684