[bug] ROG Ally: Functionality lost after sleep with mcu powersave enabled

[uejji]

On ROG Ally (may also affect Ally X, but I cannot test this) when mcu powersave is enabled, InputPlumber fails to recapture the device that provides back paddle and front button long press functionality after waking from sleep.

This seems to be the device pointed to by /dev/input/by-path/pci-0000:09:00.3-usb-0:3:1.0-event-kbd

If InputPlumber is restarted, everything captures normally and works fine until the next time the device is put to sleep.

This issue does not occur if mcu powersave is disabled.

[flukejones]

@uejji does this path /dev/input/by-path/pci-0000:09:00.3-usb-0:3:1.0-event-kbd disappear or change on resume?

[scardracs]

@uejji does this path /dev/input/by-path/pci-0000:09:00.3-usb-0:3:1.0-event-kbd disappear or change on resume?

The path exists and if you cat it and press M1 and M2 it changes

[uejji]

@uejji does this path /dev/input/by-path/pci-0000:09:00.3-usb-0:3:1.0-event-kbd disappear or change on resume?

The path remains and does not change.

[scardracs]

By the way it happens that if MCU powersave is enabled the vibrators stop working or strangely work on different ways (in my case it happened twice that the left vibrator was much stronger than right one)

EDIT: to be clear the problem with the "double vibrations" happened only on Diablo IV, not with other games so it could not be related. The lost of vibrations happened to others as weòò

[uejji]

My Ally 1 is also losing vibration completely after waking from sleep, regardless of powersave setting. Using the "Reset Device Inputs" in the controller input test page restores vibration in both cases.

[uejji]

Ally X tester reports no issues with powersave disabled, but loses vibration after waking from sleep with powersave enabled until "Reset Device Inputs" is used or InputPlumber is restarted. This tester had no issues losing M1/M2 in either case.

[flukejones]

Do any of these issues occur without inputplumber? And which kernel patch series?

[uejji]

All of us are testing on the latest version of SteamFork. I will test without InputPlumber and update.

[uejji]

Without InputPlumber, vibration comes back every single time after waking from sleep, regardless of powersave setting. M1 and M2 also work correctly after waking from sleep (tested by assigning a key to remap and using evtest)

[uejji]

I do not believe this is an issue with your patches.

[flukejones]

I suspect it may be something along the lines of a race condition where IP is trying to set things too early. On both devices it takes some seconds before the MCU are fully active again.

[flukejones]

It might be that IP needs to do a query the status of things first, see if there is a response. So I will look at adding another sysfs attribute mcu_active.. Unsure.

[uejji]

InputPlumber/src/drivers/rog_ally/driver.rs

Line 28 in 3eff7f4

std::thread::sleep(Duration::from_millis(300));

I tried increasing this delay to 1000ms, but it made no difference. Might be barking up the wrong tree, though.

[pastaq]

It might be that IP needs to do a query the status of things first, see if there is a response. So I will look at adding another sysfs attribute mcu_active.. Unsure.

Perhaps a command queue buffer for writes to the endpoint could be filled until the device is fully ready, or delay adding the interface we look for until it is ready.

[flukejones]

This is now solved in kernel. For the ally 1 the MCU triggers a reset-resume instead of a full disconnect so the config data is still live. On reset-resume pm callback I now send all settings to the MCU.

Tested in steamfork so far.

[flukejones]

Should be able to close toes in a few days once more folks test

[uejji]

Should be able to close toes in a few days once more folks test

Should we consider this resolved now?