Ayaneo Kun support

[darrencocco]

I've got an Ayaneo Kun and I'm willing to help with testing etc.

[antheas]

Hi. of course.

I will assume the speakers do not work. I know that much.

As far as the controllers go, we will need to do some reverse engineering for that.

hhd.contrib evdev will let you see which devices exist and what events they emit.

You should be able to see some MSC events for the front ayaneo buttons.

For the back buttons, I need windows ayaneo space photographs, and you will probably need to use rweverything to see how they are programmed. We need to see if we can isolate them somehow.

For the touchpads, same as above.

[darrencocco]

Okay, looks like the face buttons on the right hand side and the additional two shoulder buttons on the top are a "keyboard" mostly outputting some F-Keys. vis-a-vis the touch pads. For me they seem to be acting like a mouse with the left and right push being left and right click.

[antheas]

Classic. Yes, due to a rule in handheld daemon all keys in ayaneo are f15-f18.

Ok, so that is the same.

Run the following for me.

First, get the dmi info of the device so we can get it detected. You may omit the serial code before posting the log.

for f in /sys/class/dmi/id/*; do echo "$f:"; sudo cat $f; done | tee dmi.txt

Then, do 2 recordings, one for each touchpad with the following command:

hhd.contrib evdev | tee touchpadX.txt

Try to use the latest handheld daemon version, i think from git, as I updated the command to be more verbose.

Make sure to click and touch the touchpad. If the touchpad has the clicks coming out of a mouse, mention that too.

Does the Kun have multiple touchpad modes in windows? If yes, you might need to do recordings per mode.

Finally, try to mess with the paddles. From what i know, the device does not show them anywhere and you can only remap them to existing keys. Can you hhd.contrib evdev the AT keyboard and see if it has any MSC codes for the paddles?

[darrencocco]

So I've worked how the back paddle buttons work. They seem to be configured by the AYA Space program to emit certain key presses.

[antheas]

Can you document those options with pictures and post them?

[antheas]

Also, with hhd.contrib evdev check if they emit MSC codes

[darrencocco]

Also, with hhd.contrib evdev check if they emit MSC codes

Checked in hhd.contrib evdev and they emit the pressed and released events for the buttons I configured them for (BTN_A and BTN_B). They're part of the existing xpad controller.

I think there's a good chance they're configured through I2C.

[darrencocco]

Can you document those options with pictures and post them?

Sure bit it will take some time. I will go through and methodically capture everything in the controller configuration.

[antheas]

I do not think its I2C. In my opinion, it is either USB or direct memory writes to the EC.

If it is USB, you can follow below as you do that and capture the packets: https://github.com/hhd-dev/hwinfo/tree/master/devices#getting-the-raw-hid-descriptors

It is with wireshark and USBPcap, very safe and easy.

If it is direct memory writes to the EC, you will need RWAnything, which is a software that can read the EC memory map and to write down the memory addresses that are written.

Beware that it is a bit of a pain and shaddy to setup though. And implementing in Linux will require a kernel driver. It is outside the scope of this project to write values directly to the EC.

We only do that via manufacturer WMI ACPI calls on the legion go, where they are sanitized and specifically designed to run in userspace in windows. That is until we develop a kernel driver. Although with Lenovo not having a stable API yet (they broke the suspend light feature this bios update), I am unsure this will be done soon. Ayaneo does not do WMI yet.

[darrencocco]

I mention I2C as the audio problem is because there's an internal amplifier that needs to be initialised by I2C.

Not a problem if it is memory writes to the EC. I can work on writing the kernel driver.

[antheas]

Yes, audio amplifiers usually are connected through the i2c bus.

If it was through i2c I want to say they would have used hid and you would be able to see the device with hhd.contrib hidraw

[darrencocco]

Attached are the dmi data and recordings for the touch-pads/he PS2 Keyboard that the extra buttons on the face/shoulders show up under. The touch-pads are both reconfigurable FYI. keyboard.txt touchpad1.txt touchpad2.txt dmi.txt

[antheas]

Thanks for the data. Yes the keyboard is standard in Ayaneo devices, but seems not completely in this case.

Touchpads

I looked at the touchpad information. It is not a raw touchpad. This means Ayaneo is finally doing custom USB stuff. The touchpads are connected to the Kun MCU, which remaps them. This means that we need to first configure it in a standard way, then layer our customizations on top.

 - device /dev/input/event4, name "AYANEO AYANEO COMPOSITE DEVICE", phys "usb-0000:c4:00.3-4.2/input0"
 - device /dev/input/event5, name "AYANEO AYANEO COMPOSITE DEVICE", phys "usb-0000:c4:00.3-4.2/input1"

In this case, it is also very likely that the touchpads and paddles are configured through USB. Therefore, we need the HID descriptors of the composite device.

Therefore, you should use hid-tools to dump the descriptors from all the hidraw devices that appear to come out of this interface. The git has instructions there.

Just cut out the descriptor from the paste. We do not need the events.

This will tell us if the device has vendor hid reports that are used to configure the device. Of course, being a new manufacturer, Ayaneo might have gimped the descriptors and even if there are configuration commands they might be missing.

Then, you can use Wireshark with USBPcap in windows to sniff the configuration data from the device. Given the hid descriptors, fishing them out will be easy.

Keyboard

HHD already contains a systemd rule about Ayaneo devices that maps their scancodes to keycodes. But it seems like the Kun has a different set of scan codes. Therefore, I upgraded hhd.contrib evdev to print the scan codes in hex.

Can you redo the keyboard recording with the new version from git, and put a button name to the scancodes?

Preview:

┌─────────────────────────────────────────────────────────────────┐
│ 103.708s / EV_MSC (004) /              MSC_SCAN (004):   0x00B0 │
│ 103.708s / EV_KEY (001) /          KEY_VOLUMEUP (115): released │
└ SYN ─ 104.809s ─    6.5 Hz ─────────────────────────────────────┘

[darrencocco]

hidraw0_recording.txt hidraw1_recording.txt hidraw2_recording.txt scancodes_LC.txt scancodes_RC.txt scancodes_TouchButton.txt scancodes_AYAButton.txt scancodes_=Button.txt

[antheas]

hidraw2 is a configuration interface. You should be able to sniff it with Wireshark and USBPcap in windows.

Just select the USB device of the controller with the gear icon before recording.

And make sure to launch it with administrator priviledges. So it does not open UAC between recordings.