flozz / rivalcfg

CLI tool and Python library to configure SteelSeries gaming mice
https://flozz.github.io/rivalcfg/
Do What The F*ck You Want To Public License
767 stars 62 forks source link

Aerox 3 Wireless #167

Closed gort818 closed 1 year ago

gort818 commented 2 years ago

I did some reverse engineering this week, got quite a bit done, Attached is what I have found so far. ACTIVE LED colors are not saved to device memory all other settings seem to be. I could not write to the device unless I was root.. Udev rules are in place and no luck.

For the LEDs I have a systemd service running every few seconds just like the Steel Series Software.

Wireless Mode: VID:1038 PID:1838

Wired Mode: VID:1038 PID:183a

Below is what I have found out so far.

WIRELESS: aerox3-wireless.txt

WIRED: aerox3-wireless-wired.txt

Here is repo I created as well, I will update it as I find more info https://github.com/gort818/aerox3-wireless

flozz commented 2 years ago

Thank you for your tests. I hope I will be able to finish the Aerox 3 Wireless support by the end of the week :)

mewtlu commented 2 years ago

Been having some issues this morning with my Ubuntu machine not noticing the mouse even after replugging it and trying it both wired and wireless, though at some point it just started working fine in both modes, but since then I seem to be having issues with the scroll where it seems to disable for ~0.5s every few seconds of constant scrolling?

I've also noticed there's some jitters with the cursor movement for a couple seconds right after setting my sensitivity, and the "Data:" log is just echoing out an empty array now.

While typing this out the mouse also just suddenly stopped responding at all until I re-plugged it, and now strangely the cursor is completely jittery.

Apologies if this info doesn't help much, just had some weird cases I've not seen before so thought I'd report in case it might be related to the software. Let me know if there's anything else I can provide to help work out what might be happening here. Thanks!

Edit: Plugged the mouse directly into a USB 3 port rather than a 2.0 on an extender with power issues and that appeared to fix the jitter issues, though the mouse still stopped working a few seconds after running the sensitivity command and the Data log seems intermittent, so some of these issues may have just been caused by low power?

I also ran rivalcfg -r in hopes it might fix the scroll issue and it reset the sensitivity but it doesn't appear to have affected the scroll. The issue seems to be prevalent after a reboot, and upon startup I got some "USB: Unable to enumerate device" errors. Taking a look at my syslog when plugging the device in I see the following:


Nov 24 10:45:19 omega kernel: [  365.929167] usb 1-5.2: new full-speed USB device number 34 using xhci_hcd
Nov 24 10:45:19 omega kernel: [  366.056997] usb 1-5.2: device descriptor read/64, error -32
Nov 24 10:45:19 omega kernel: [  366.297020] usb 1-5.2: device descriptor read/64, error -32
Nov 24 10:45:19 omega kernel: [  366.537078] usb 1-5.2: new full-speed USB device number 35 using xhci_hcd
Nov 24 10:45:19 omega kernel: [  366.669236] usb 1-5.2: device descriptor read/64, error -32
Nov 24 10:45:20 omega kernel: [  366.905012] usb 1-5.2: device descriptor read/64, error -32
Nov 24 10:45:20 omega kernel: [  367.013275] usb 1-5-port2: attempt power cycle
Nov 24 10:45:21 omega kernel: [  368.541227] usb 1-5.2: new full-speed USB device number 36 using xhci_hcd
Nov 24 10:45:21 omega kernel: [  368.541384] usb 1-5.2: Device not responding to setup address.
Nov 24 10:45:21 omega kernel: [  368.753245] usb 1-5.2: Device not responding to setup address.
Nov 24 10:45:22 omega kernel: [  368.960948] usb 1-5.2: device not accepting address 36, error -71
Nov 24 10:45:22 omega kernel: [  369.088964] usb 1-5.2: new full-speed USB device number 37 using xhci_hcd
Nov 24 10:45:22 omega kernel: [  369.089153] usb 1-5.2: Device not responding to setup address.
Nov 24 10:45:22 omega kernel: [  369.297337] usb 1-5.2: Device not responding to setup address.
Nov 24 10:45:22 omega kernel: [  369.508962] usb 1-5.2: device not accepting address 37, error -71
Nov 24 10:45:22 omega kernel: [  369.509256] usb 1-5-port2: unable to enumerate USB device```
flozz commented 2 years ago

@mewtlu The powering issue may have corrupted the internal memory? Can you try to plug the mouse on a Windows machine with the SSE3 to try to reset everything / update the firmware?

flozz commented 2 years ago

I just pushed the property implemented readback feature for the Wireless mode and added tests. The only missing features are the ones related to power management (sleep timer, etc.). I will try to implement this before merging on master

mewtlu commented 2 years ago

It seems SSE doesn't have any way of forcing a firmware update and it will only prompt if it notes the firmware version is out of date, any idea whether we might be able to decrease the version number on the device to try trigger the update prompt?

flozz commented 2 years ago

No I have no idea :(

vith commented 2 years ago

@mewtlu I found these instructions for resetting a different SteelSeries mouse. Maybe something similar will work for the Aerox 3 Wireless?

1) Unplug your mouse. 2) Hold down the left, right, and CPI (the button directly under the mouse wheel) buttons together 3) Plug your mouse back in. Continue holding buttons for 5 seconds until the LEDs on the mouse blink.

https://www.reddit.com/r/steelseries/comments/cbvsa5/reset_steelseries_mouses_internal_flash_memory/

mewtlu commented 2 years ago

Thanks vith, I saw that too but unfortunately it doesn't appear to do anything for my Aerox as far as I can tell. And no worries flozz, I'll try having a play with Wireshark on SSE later and see if I can work out where the firmware version check is being done and whether I might be able to update it or trick SSE into thinking it's something else.

flozz commented 2 years ago

I merged the branch to master.

I do not implemented the "power saving" features yet, I will work on this later.

Published in v4.4.0

bitnimble commented 2 years ago

I have a 2022 version of the Aerox 3 Wireless, and the battery level doesn't seem to be correct when in wireless mode (--battery-level reports -5%). Possible that the HID command or battery level logic has changed?

I didn't debug it, but a response of 0x00 would result in a decimal -5 output: https://github.com/flozz/rivalcfg/blob/master/rivalcfg/devices/aerox3_wireless_wired.py#L138

so perhaps the id / command has changed?

fluffynuts commented 2 years ago

it's quite likely that it's changed - afaik the newer revision is practically a new piece of hardware, sharing a name only

finnjames commented 2 years ago

To correct the lack of on-device memory for LED colors, I put together a daemon that runs a shell script upon recognizing the Aerox 3 Wireless. It appears to work upon both plugging in the 2.4GHz receiver and when powering on the mouse. Unfortunately, setting it up is a bit involved and it uses systemd so it's currently macOS only, but check out this gist if you had this issue and want to see my solution.

flozz commented 1 year ago

The support of this mouse has been improved in Rivalcfg v4.6.0: sleep and dim timers are now configurable.

adamdev-id commented 1 year ago

WOAH THANK YOU GUYS